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Description 

CROSS REFERENCE TO RELATED APPLICATIONS 

[0001] This application claims priority to Applicant's copending application having U.S. Serial No. 60/111,029 
filed December 4, 1999. 

FIELD OF THE INVENTION 

[0002] The present invention relates generally to automated financial transactions and, more particularly, to a 
10 method and system for performing multibank automated financial transactions involving currency exchange. 

BACKGROUND OF THE INVENTION 

[0003] In the past, currency exchange transactions, for example, for a business organization in connection with 
pricing foreign goods/sen/ices were time and labor intensive, because the exchange rate was generated manually by a 

IS trader. Further, there was a lack of uniformity in rates, because different traders often quoted different rates 
based on subjective considerations. Additionally, since trades were done by telephone, there was generally a lack of 
an audit trail. Also, there was a great deal of uncertainty because of rate fluctuations over relatively short 
periods of time. Applicant's U.S. Patent No. 5,787,402 addressed many of those problems by providing a method and 
system for performing financial transactions involving foreign currency deals in virtually all trading currencies 
which automatically incorporated the current market process and operated in a secure environment 
[0004] According to Applicant's U.S. Patent No. 5,787,402, customers can access the system on-line and in real 
time through various terminals, such as a personal computer. By inputting information in response to prompts on the 
computer screen, the system quickly identifies the nature of the transaction which the customer desires. The system 
then automatically generates an offer in response to the customer's request based upon a number of parameters, 
including the market price, the size and nature of the transaction, and the size and nature of the client. The 

25 system then promptly displays the bank's offer to the customer. The customer is then given an opportunity to accept 
the offer, ask that the offer be updated, or reject the offer. If the customer delays for too long, the system 
automatically withdraws and updates the offer, thereby protecting the bank from liability for a "stale" rate. If 
accepted, the trade is automatically forwarded for processing and assigned a reference number for tracking and 
control purposes. 

[0005] While the system of Applicant's U.S. Patent No. 5,787,402 affords an effective automated system for 
30 financial transactions involving foreign currencies vwth a single bank, many organizations are required to receive 
multiple foreign exchange quotes in transactions which exceed a certain specified amount Further, many 
organizations have policies which require competitive quotations in any foreign exchange. Thus, there is a current 
need for a method and system for perforrhing multibank automated financial transactions involving foreign currencies. 

SUMMARY OF THE INVENTION 

35 

[0006] It is a feature and advantage of the present inventon to provide a method and system for performing 
multibank automated financial transactions involving foreign currency which enables trading of foreign currency on a 
standing price. 

[0007] It is another feature and advantage of the present invention to provide a method and system for 
4Q performing multibank automated financial transactions involving foreign currency which assures a nondiscriminatory 
price presentation in which the prices are presented as quotes received, in which one bank does not hold back 
another, and in which rate time-outs are handled independently. 

[0008] It is an additional feature and advantage of the present invention to provide a method and system for 
performing multibank automated financial transactions involving foreign currency which allows flexibility of 
installation, including various network configurations, and co-existence of graphic user interfaces with other 
45 personal computer applications on multi-use terminals and personal computers. 

[0009] It is a further feature and advantage of the present invention to provide a method and system for 

performing multibank automated financial transactions involving foreign currency which affords flexibility in 

implementation, such as allovyring participating banks to implement their own pricing algorithms and to extract their 

own spreads and impose different trading limits and controls on users based on their own internal criteria. 

[0010] It is still another feature and advantage of the present invention to provide a method and system for 

performing multibank automated financial transactions involving foreign currency which assures impartiality in 

implementation. 

[0011] It is a still further feature and advantage of the present invention to provide a method and system for 
performing mulitbank automated financial transactions involving foreign currency which leverages current systems and 
technology. 

55 [0012] To achieve the stated and other features, advantages, and objects, an embodiment of the present invention 
provides a method and system for performing multibank financial transactions involving foreign currencies based upon 
a number of discrete, standing price foreign exchange dealing systems, each operating under the control of a 
participating financial institution, such as a bank. A customer-user communicates with each of the discrete dealing 
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systems across a private, secure network and can secure competitive quotes without having to redial into or log in 
separately to a plurality of systems. 

[0013] In an embodiment of the present invention, a plurality of participating financial institutions, such as 
banks, each operates a foreign currency exchange dealing system. Each system receives a feed of foreign currency 
exchange price quotes from within the particular bank and provides executable quotes to a user across a network in 
* response to the user's request for quotes. A user interface, such as a graphical user interface or computer user 
interface, on the user's computer terminal, such as the user's personal computer, simultaneously sends a message to 
the dealing system of each participating bank to obtain an executable quote. As the replies from the banks' dealing 
systems are received, the user interface displays them on the screen of the user's computer terminal and offers real- 
time comparison. The user can then select a particular price quote for execution. 

[0014] In an embodiment of the present invention, when the price quote is selected by the user, a message is 
sent from the user interface on the user's computer terminal to the dealing system of the chosen bank to accept the 
price quote. This causes the bank's dealing system to determine whether the price quote is still valid and accept or 
reject the currency exchange transaction, the outcome being sent back to the user interface and displayed for the 
user on the screen of the user's computer terminal. If accepted, the dealing system of the chosen bank hands off the 
selection to the bank's deal capture system for settlement. The system for an embodiment of the present invention 
15 makes use of a multibank interface which consists of a number of public remote function calls which are resolved 
within a particular participating bank's foreign exchange currency dealing system. These function calls allow the 
dealing system of the particular bank, for example, to receive quote requests from the network, return price quotes, 
and list transactions. 

[0015] In an embodiment of the present invention, a user's request for a price quote for a currency exchange 
transaction is received, for example, by the user entering the request on a user interface, such as a graphical user 
interface or a computer user interface, of the user's computer terminal. The user enters a selection of one or more 
parameters for the transaction, such as "Spot," "Fonward," and "Swap," as well as a selection to "Get Quote," and the 
request for quote is automatically sent by the user interface of the user's computer terminal simultaneously to the 
currency exchange dealing systems of each of the plurality of participating financial institutions. 
[0016] An embodiment of the present invention makes use of a security application on the user's computer 

25 terminal for automatically authenticating the user. The request for quote is automatically sent simultaneously to 
each of the currency exchange dealing systems by the user interface on the user's computer terminal, which is 
preconfigured with information about each of the participating financial institutions, such as a network address and 
security information. The request is sent to each of the dealing systems over a secure network, such as a virtual 
private network, to which the user's computer terminal is connected, for example, over a dial-up, an integrated 
sen/ices digital network, or a dedicated line. 

30 [0017] In an embodiment of the present invention, each dealing system receives a feed of currency exchange price 
quotes and stores executable price quotes on a table in a repository of price quotes maintained by the dealing 
system. Upon receiving the request for the price quote, each dealing system automatically returns an executable 
price quote from its repository of price quotes over the secure network to the user interface on the user's computer 
terminal, where the price quote of each of the dealing systems is automatically displayed for the user. The price 
quotes are displayed in real time as they are returned by each dealing system for real-time comparison by the user. 

2* The user's selection of one of the price quotes is received by the user entering the user's selection of the 
particular price quote on the user interface of the user's computer terminal. 

[0018] In an embodiment of the present invention, when the user enters his or her selection, the selection is 
automatically sent by the user interface on the user's computer terminal over the secure network to the particular 
currency exchange dealing system which furnished the selected price quote. If the selection is received by the 

40 particular dealing system within a predetermined time after the deaCng system furnished the price quote, such as 
ten seconds, the dealing system automatically reviews the selection against one or more predefined parameters for 
the user, such as a credit allocation for the user, a maximum transaction size for the user, and a delivery limit 
for the user, and automatically confirms the selection. Otherwise, if the selection Is not received within the 
predetermined time, in order to avoid a "stale" price quote, for example, the selection is rejected and the price 
quote updated by the dealing system. 

45 [0019] In an embodiment of the present invention, the particular dealing system automatically confirms the 
selection, for example, by automatically sending a confirmation of the price quote selection for the currency 
exchange transaction over the secure network to the user interface on the user's computer terminal, where the 
confirmation is displayed for the user. In addition, the particular dealing system hands the selection off to a deal 
capture system of the dealing system for settlement of the currency exchange transaction with the user. Optionally, 
the settled transaction is handed off by the dealing system, for example, over a proprietary network, such as the 

^ S.W.I.F.T. network, to a match application for matching between the financial institution side of the ti-ansaction 
and the user side of the b-ansaction. 

BRIEF DESCRIPTION OF THE DRAWINGS 

« [0020] 



Fig. 1 is a schematic diagram which illustrates an example ovennew of key components and the flow of 
information between the key components of the multibank currency exchange trading system for an embodiment of 



the present invention; 
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Fig. 2 is a schematic diagram which provides further detail regarding an example of the secure network and the 
flow of information over the secure network of the multibank currency exchange trading system shown in Fig. 1 for 
an embodiment of the present invention; 

Fig. 3 is a schematic diagram which provides further detail regarding an example of the client side installation 
of the multibank currency exchange trading system of Fig. 1 for an embodiment of the present invention; 

Fig. 4 is a schematic diagram which provides further detail regarding an example of the bank Installation for 
connecting to the multibank currency exchange trading system of Fig. 1 for an embodiment of the present invention; 
and 

Fig. 5 is a flow chart which illustrates an example of a currency exchange transaction for a user over the 
multibank currency exchange trading system of Fig. 1 for an embodiment of the present invention. 



DETAILED DESCRIPTION OF THE INVENTION 

[0021] Referring now in detail to an embodiment of the present invention, an example of which is illustrated in 
the accompanying drawings, Fig. 1 is a schematic diagram which illustrates an example overview of key components 
and the flow of information between the key components of the multibank currency exchange trading system 2 for an 

20 embodiment of the present invention. Referring to Fig. 1, each of a plurality of participating banks 4, 6, and 8 
operates a foreign exchange dealing system 10, 12, and 14. The system and method for an embodiment of the present 
invention is based upon a number of discrete, standing price foreign exchange dealing systems 10, 12, and 14, each 
operating under the control of the owner bank 4, 6, and 8. Customers 16, 18, and 20, such as corporate/fund managers 
and the like, at their respective terminals 22, 24, and 26, communicate vi^tii each of the dealing systems 10, 12, and 
14 across a private, secure network 28. 

25 [0022] The system for an embodiment of the preisent invention makes use, for example, of basic functionality 
regardless of implementation. Each of the participating banks 4, 6, and 8 operates a foreign exchange dealing system 
10, 12, and 14, such as the system of Applicant's U.S. Patent No. 5,737,402, incorporated herein by this reference. 
Each foreign exchange dealing system 10, 12, and 14 receives a feed of foreign exchange prices 30, 32, and 34 from 
within the particular bank 4, 6, or 8, provides executable quotations to customers 16, 18, and 20 across the network 

3Q 28, and hands off completed transactions to the particular bank's deal capture system 36, 38, or 40. 

[0023] In an embodiment of the present invention, the foreign exchange dealing system 10, 12, and 14 of each 
participating bank 4, 6, and 8 receives a feed 30, 32, and 34 of foreign exchange prices from within the bank. These 
prices are typically a conglomeration of external feeds, prices obtained from the dealing room, and include other 
factors to "massage" the rates. The rates are further manipulated and controlled by the bank-user, such as a member 
of staff at the bank that is responsible for the foreign exchange dealing system 10, 12, or 14. This individual is 

35 responsible for setting and maintaining limits on the system foreign exchange dealing system 10, 12, or 14, 
monitoring the timeliness and availability of prices, and controlling the availability of the foreign exchange 
dealing system to the customers 16, 18, or 20. 

[0024] In an embodiment of the present invention, the foreign exchange rates are temporarily stored in a table 
within the foreign exchange dealing system 10, 12, or 14, such that the latest rate is always available for customer 
quotation. In this wray the foreign exchange dealing system 10, 12, or 14 can respond to a request for a price from a 
customer 16, 18, or 20 Immediately, without waiting for a trader or administrator to input or authorize a price. In 
order to simplHy the implementation and operation of the system 2 for an embodiment of the present invention, the 
foreign exchange dealing systems 10, 12, and 14 use the standing-price method of dealing. The quotations presented 
to the customer 16, 18, or 20 are good for a specific time period, such as ten seconds, determined by parameters 
wittiin the foreign exchange dealing system 10, 12, or 14. Once quoted, the customer 16, 18, or 20 can accept the 
^ price at any time during this period regardless of the movements in the foreign exchange market The arbitrage risk is 
mitigated by a combination of the relatively small deal sizes and the relatively high spreads. 

[0025] In an embodiment of the present invention, the outcome of the foreign exchange trade is determined by the 
foreign exchange dealing system 10, 12, or 14. If the customer 16, 18, or 20 decides to accept a quotation, the 
dealing system 10, 12, or 14 reviews the acceptance against other parameters held against the customer's account. 
These parameters include, for example, credit allocation, maximum transaction size, delivery limits, and the like. 
50 This differs, for example, from telephone trading in which the trade is done the moment the customer accepts the 
price. Completed transactions are handed-off to the respective deal capture systems 36, 38, or 40 of the banks 4, 6, 
or 8 for automated processing. This interface replaces the dealers' manual input of transactions to a blotter, 
substantially reducing operational risk and costs. 

[0026] In an embodiment of the present invention, the customer side of the completed transactions are then 
handed-off to a foreign exchange match application 42 to be matched against the bank's side, which are received 
across a network 44, such as the S.W.I.F.T. network. In this way, the customer's deals are automatically confirmed 
and listed alongside the larger tiransactions that may have been executed over the telephone. 
[0027] An embodiment of the present invention also makes use of a multibank interface 46, 48, and 50. The 
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system 2 for an embodiment of the present invention utilizes, for example, a dealing system similar to the system of 
Applicant's U.S. Patent No. 5,737,402 as the foreign exchange dealing system 10, 12, and 14 at each of the 
participant banks 4, 6, and 8. In the case where a particular bank already has an established standing-price foreign 
exchange trading engine, the bank may use the multibank interface 46, 48, or 50 to adapt it to the multibank network 
28. The multibank interface 46, 48, and 50 consists of a small number of public remote function calls which must be 
resolved within the foreign exchange dealing system 10, 12, or 14 of the bank 4, 6, or 8. These function calls allow 
the foreign exchange dealing system 10, 12, or 14, for example, to receive quote requests from the network 28, 
return prices, list transactions, and the like. 

[0028] An embodiment of the present invention makes use of a multibank graphical user interface (GUI) 22 and 24. 
A customer 16 or 18 accesses the multi-bank environment 2 via a graphical user interface (GUI) application 22 or 24 
that runs, for example, on the customer's local personal computer (PC). The GUI application 22 and 24 contains a 
number of screens to enter parameters describing foreign exchange transactions, including "Spot," "Forward," and 
"Swap." Once entered, the GUI 22 or 24 performs checks to ensure that sufficient parameters have been entered and 
that the fields are in the correct format. The customer 16 or 18 may then press a "Get Quote" key. 
[0029] An embodiment of the present invention also makes use of a multibank computer user interface (GUI) 26. 
The multibank GUI 26 is, for example, a number of Microsoft object linking embedded (OLE) servers that permit a 
customer 20 to write an application that can automatically trade foreign exchange with the multibank network 28. The 
customers, such as customer 20, may "embed" the GUI 26 into their banking systems, such as banking system 52, 
thereby improving efficiency and further cutting cost. The GUI 26 connects to the secure network 28 and 
interoperates wnth the banks 4, 6, and 8 in exactly the same manner as the GUI 22 or 24. All the functions supported 
by the GUI 22 and 24 are replicated in the GUI 26, including, for example, quotation, transaction execution, and 
transaction summaries. 

[0030] In an embodiment of the present invention, when the "Get Quote" key is pressed, the GUI 22 or 24 or the 
GUI 26 simultaneously sends a message to each of the banks 4, 6, and 8 to obtain an executable rate. As the replies 
from the banks 4, 6, and 8 are received, the GUI 22 or 24 or the GUI 26 displays them on the screen and offers a 
real-time comparison of the prices. The customer 16, 18, or 20 may then select a particular price, or the best price 
offered for execution. When the price is accepted, a message is returned to the chosen bank 4, 6, or 8 to accept the 
quote, which causes the particular bank 4, 6, or 8 to determine if the quotation is still valid and either accept or 
reject the transaction, the outcome being displayed on the GUI screen 22 or 24 or the GUI screen 26. 
[0031] In an embodiment of the present invention, the GUI 22 and 24 or the GUI 26 may also be used to re\riew the 
prices available from any of a number of trading partners, such as banks 4, 6, or 8. The GUI screen 22 and 24 and 
the GUI screen 26 operates in two modes, including, for example, a comprehensive view of rates offered by a 
particular bank 4, 6, or 8 and a comparison of rates offered by the trading partners 4, 6, and 8. The GUI 22 and 24 
and the GUI 26 likewise provides a "View Transaction" function which obtains a summary of transactions that have 
been entered or executed. The function provides a number of optional filters to help select the desired information, 
including date range, counterparty, currency, and the like. Once the selection criteria have been established, the 
GUI 22 or 24 or the GUI 26 sends a request to each of the trading partners, such as banks 4, 6, and 8 to request the 
transactions. The responses are tabulated in a summary grid on the GUI screen 22 or 24 or the GUI screen 26. 
[0032] An embodiment of the present invention makes use of trading configuration. Gommunication between a 
customer 16, 18 or 20 and a particular bank 4, 6, or 8 is restricted by trading relationships, such as entitiements 
and credit. Before the GUI 22 or 24 of the customer 16 or 18 or the GUI 26 of the. customer 20 and the bank's foreign 
exchange dealing system 10, 12, or 14 can communicate, the GUI 22 or 24 or the GUI 26 must be configured with the 
network address and security details of the bank 4, 6, or 8, and the bank must be configured with the customer's 
profile and account details. This information is exchanged between the customer 16, 18, or 20 and bank 4, 6, or 8 
when the trading relationship is first established. 

[0033] It is not necessary for the customer 16, 18, or 20 to maintain a trading relationship with all the banks 

4, 6, and 8 participating in the multibank system 2 for an embodiment of the present invention. The GUI 22 or 24 and 
the GUI 26 only obtains quotes from the particular banks that are configured and ignores the remaining banks, unless 
a function such as a "back-to-back" is agreed in advance among credit and non-credit banks. The remaining banks are 
not aware that the particular customer exists, since for example, there is no centralized store of information and 
the like. In this way, the trading activity and profiles are private between the particular bank and a particular customer. 
[0034] An aspect of an embodiment of the present invention utilizes a foreign exchange match interface 54. In 
addition to the deal capture hand-off, each of the foreign exchange dealing systems 10, 12, and 14 can fonvard their 
customer deals to the foreign exchange match application 42 for automated confirmation. This function Is optional, 
depending on whether the customer 16, 18, or 20 and bank 4, 6, or 8 are both subscribers to the foreign exchange 
match system 42. When a transaction is "released," the foreign exchange dealing system 10, 12, or 14 constructs a 

5. W.I.F.T. MT300 foreign exchange confirmation message containing the details of the transaction from the 
perspective of the customer 16, 18, or 20. The MT300 message is delivered to the foreign exchange match application 
42 across the secure network 28. The foreign exchange match application 42 parses the MT300 message and stores 
the deal as the customer side of an unmatched transaction. 

[0035] In an embodiment of the present invention, the bank's version of the transaction is received in a 
conventional manner. When the transaction is released, the foreign exchange dealing system 10, 12, or 14 transmits 
the details to the bank's deal capture system 36, 38, or 40. From here the deal is propagated to a settiement system 
of the bank 4, 6, or 8, resulting in the production of an MT300 message from the bank's perspective. This message is 
delivered to the foreign exchange match application 42 over the S.W.I.F.T. network 44, where It is automatically 
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matched with the customer's message. Apart from providing automatic end-to-end confirmation, the bank 4, 6, or 8 can 
include settlement instructions and other related information to enrich the entry on the foreign exchange match 
system 42. 

[0036] An embodiment of the present invention makes use of the secure network 28. Fig. 2 is a schematic diagram 
which provides further detail regarding an example overview of the secure network 28 and the flow of information 
over the secure network 28 for an embodiment of the multibank currency exchange trading system 2 of the present 
invention. Referring to Fig. 2, the integrity of the multibank electronic foreign exchange execution system 2 for an 
embodiment of the present invention is predicated on the security of the network 28 needed to carry the messages 
between counterparties, such as customers 16, 18, and 20 on the one hand, and banks 4, 6, and 8 on the other hand. 
[0037] The system 2 for an embodiment of the present invention is implemented using a distributed, client-server 
architecture implemented over a Transmission Control Protocol/Internet Protocol (TCP/IP) network 28. Fig. 3 is a 
schematic diagram which provides further detail regarding an example of the client side Installation for access to 
the system 2 for an embodiment of the present invention. Referring to Fig. 3, a client, such as customer 16, 18, or 
20 accesses the system 2 using a GUI 22 or 24 or CUI 26 running on a Windows PC 56 connected to a virtual private 
network (VPN) 28 via a dialup 58, an Integrated Services Digital Network (ISDN) 60, or if necessary, a dedicated 
connection, such as a leased tine. Customers 16, 18, or 20 accessing the bank servers 10, 12, or 14 for foreign 
exchange rates and trade execution have the option of using Plain Old Telephone Sennce (POTS) dialup 58 or ISDN 
60. It Is not anticipated that a dedicated network link is needed by the customers 16, 18, or 20 due to traffic 
volume, but it is also available as an option. 

[0038] Fig. 4 Is a schematic diagram which provides further detail regarding an example of the bank installation 
for connecting to the system 2 for an embodiment of the present invention. Referring to Fig. 4, each member bank 4, 
6, 8 has a system 62 connected to the virtual private network 28 running software capable of handling Remote 
Procedure Calls (RPCs) from the client GUI 22 or 24 or CUI 26. In an embodiment of the present invention the 
financial institution system implements an application sen/er or RPC server 62 capable of supporting RPCs which 
reply to requests for foreign exchange rate quotations and execution of foreign exchange trades. The RPCs are in the 
format defined, for example, by the Open Software Foundation (OSF) Distributed Computing Environment (DCE) 
specification, which is a recognized industry standard. The goal of this network solution is simplicity, uniformity, 
scalability, and being highly fault tolerant, exhibiting high availability. 

[0039] The system 2 for an embodiment of the present Invention Includes one or more security applications which 
function as a firewall 64. Management of the firewall 64 is over a secure TCP/IP link to the virtual private network 
28. Security of the link requires user authentication and Data Encryption Standard (DES) encryption to the firewall 
28. In order to authenticate the end user to. the system 2, system software transparentiy performs mutual 
challenge/response authentication for each session that is created. The mutual challenge/response authentication 
requires each party to send the other party a random number, which the other party returns encrypted under a secret 
key known to both parties. 

[0040] The security softvrare at the heart of the configuration for an embodiment of the present invention is the 
firevrall 64. It is anticipated, for example, that a third-party vendor will administer the firewall 64 for the 
multibank system 2. Management of the firewall 64 is over the secure TCP/IP link to the virtual private network 28 
built specifically for the multibank system 2. Security of that link is implemented using technology that provides 
user authentication and DES encryption to the firewall 64. 

[0041] The system for an embodiment of the present invention is implemented over a single-vendor Frame Relay 
TCP/IP Virtual Private Network (VPN) 28. All member banks 4, 6, and 8 are directiy connected 24 hours a day, seven 
days a week, for example, through 64kbps links 64, with ISDN backup 66 for minimal downtime under failure. A 
standard building block is used at each bank with a common carrier managed service to the public-side part of the 
firewall 64, such as a firewall available from V-One Corporation. The goals of the network solution for an 
embodiment of the present Invention are simplicity, uniformity, scalability, and being highly fault tolerant, 
exhibiting high availability. Remote access to the firewall 64 for administration is secured by use of a direct link, 
for example, from the firevrall vendor, such as V-One Corporation, to the VPN 28. Security software, such as 
SmartGate security software available from V-One Corporation, is used for all remote support of the firewall 64. A 
single point of failure probability is low and can be optimized, for example, at the option of a member bank 4, 6, 
or 8 at additional cost. 

[0042] In an embodiment of the present invention all firewalls 64, for example, are installed, maintained, and 
administered by the vendor of the firevy^yi 64. To ensure Independent, trusted contool, only authorized staff of the 
firevrall vendor can access the firewall 64. Member banks 4, 6, and 8 are not permitted write access to the firewall 
64 but may have read access to statistics relating to connections to the firewall 64 on their premises. 
Admlnisti-ation of the firewall 64 is performed remotely by the security software vendor using a secure TCP/IP link 
to the virtual private network. Security of the link is implemented using technology, such as SmartGate technology 
from V-One Corporation, the same used for providing user authentication and DES encryption to the firewall 64. 
[0043] In an embodiment of the present invention, security software, such as SmartGate software available from V- 
One Corporation, is software that works with the firewalls available from various vendors to provide secure access 
to member bank networks and systems. Referring further to Fig. 3, each client system 16, 18, or 20 must have 
security software 70 loaded and running to successfully connect to a member bank network or system 4, 6, or 8 
protected by the firewall 64 tiiat Is enabled, for example, for SmartGate available from V-One Corporation. The 
security software 70 provides, for example, dual challenge mutual authentication of each user and 56 bit DES 
encryption of the established session, which means that each side of the connection must authenticate itself to the 
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other. 

[0044] In an embodiment of the present invention, each customer user 16, 18, and 20 is issued, for example, a 
smart card which contains the authentication key for the firewall 64 of each bank 4, 6, and 8. The user 16, 18, or 
20 must register with each bank 4, 6, or 8 to obtain the respective authentication key. This key is obtained when 
the user 16, 18, or 20 runs, for example, an on-line registration application, such as the V-One On-Line 
® Registration Wizard, from his or her PC 22, 24, or 26 to connect to the firewall 64 and initiate the process which 
uses a multi-step encrypted exchange of keys. As new member banks become part of the network 2, customer users 
16, 18, or 20 must register with the new bank's firewall to receive executable rates and perform trades. If 
electronic key distribution is not desired, the user authentication keys can be distributed using conventional 
mailings, separate from the distribution of the smart cards used to store the keys. 

[0045] In an embodiment of the present invention, the security software is based on personal access in which 
users 16, 18, or 20 are identified rather than machines. Each user 16, 18 or 20 has some method of personal 
identification, such as a smart card. A security server, such as a SmartGate server available from V-One Corporation, 
holds a list of known users, their smart card details, and which applications and servers they are allowed to 
access. The security server also supports virtual (hard or floppy disk based) smart cards (or tokens), which do not 
require physical distribution. The user 16, 18, or 20 does not have to work his or her way through a complex set of 
15 challenges and responses. The security client software 70 does this for them. The user 16, 18, or 20 simply svt^pes 
his or her smart card and enters a secret code to unlock the smart card. 

[0046] In an embodiment of the present invention, integrated into the security software is a complete suite of 
authentication technologies, seamlessly providing the ability to mix and match multiple forms of authentication for 
the same application, on a user-by-user basis. For example, the authentication system, such as an authentication 
system available from V-One Corporation, supports ISO standard smart cards for both authentication and stored data, 

20 as well as virtual smart cards, authentication cards, and X.509 digital certificates. The application level 
client/server security system is designed to provide tightly controlled access to TCP-based services behind a 
firewall, vt/ithout requiring changes in the application or system software on the user's desktop. 
[0047] In an embodiment of the present invention, the security system client side application 70, runs on the 
desktop of the customer/user 16, 18, or 20 running, for example, on Windows, Windows 95, Windows NT, or Apple 

25 Macintosh. Rather than using a Dynamic Link Library (DLL), replacement Winsock or replacement protocol stack, the 
security client 70, for example, is a separate application, which runs in its own address space. The end user's 
application communicates vynth the security client 70 which, in turn, communicates with the security server on the 
firewall 64; over an encrypted link. 

[0048] In an embodiment of the present invention, the application does not have to understand that the security 
system is in place, either at the client end or at the server end. For applications in which security is being 
30 provided to a large end user base, this is a major advantage, since it reduces support costs. Trying to deploy a 
replacement protocol stack-based application, for example, to a million users is extremely expensive if there are 
any significant compatibility problems. Using the pure application-based approach is the most direct and easiest to 
support. 

[0049] In an embodiment of the present invention, the security client 70 manages authentication and encryption 
„ between the desktop and the security server, but it is the server which manages access control. Within the security 
server is a complete access control database, allowing the administrator to assign each user 16, 18, or 20 to groups, 
and to apply user or group-level permissions on what applications they may access.through the server. 
[0050] In an embodiment of the present invention, all connection records are maintained by the security server 
for later analysis, and can be used to fonn the basis of a pay-per-access application. Since the security server 
only completes connections that are authenticated and permitted by its access control tables, systems behind the 
40 firevrall 64 never receive a connection that has not been pre-validated. The connection that is made, however, is an 
ordinary TCP connection, so the server software does not require any alteration. 

[0051] In an embodiment of the present invention, the security client 70 presents the user 16, 18, or 20 with a 
customizable pop-up dialogue box, which includes the ability for the user 16, 18, or 20 to specify how long the 
session should remain active. This value can be overridden by the administrator at the security server to 
accommodate site policy. While the security client 70 is "unlocked," the user 16, 18, or 20 can initiate other 

^ sessions without further prompting. 

[0052] Fig. 5 is a flow chart which illustrates an example of a currency exchange transaction over the multibank 
currency exchange system 2 for an embodiment of the present invention. Referring to Fig. 5, at SI, a user, such as 
customer 16, 18, or 20, at a user terminal, such as GUI 22 or 24 or CUI 26, coupled to secure network 28, enters 
foreign currency exchange transaction parameters and a request to "Get Quote." At S2, the user terminal 22, 24 or 26 
automatically sends the request for quote simultaneously over the network 28 to the currency exchange dealing 
systems 10, 12, and 14 of each of a plurality of financial institutions, such as banks 4, 6 and 8. At S3, the 
currency exchange dealing system 10, 12, and 14 of each financial institution 4, 6, and 8 receives the request and 
automatically returns an executable price quote from a repository 30, 32, and 34 of foreign currency exchange prices 
maintained by each financial institution 4, 6, and 8 to the user terminal 22, 24, or 26 over the network 28. 
[0053] Referring further to Fig. 5, at S4, the user terminal 22, 24, or 26 receives and automatically displays 

55 the price quote received from the foreign exchange dealing system 10, 12, and 14 of each of the financial 
institutions 4, 6, and 8 for the user 16, 18, or 20. At S5, the user 16, 18, or 20 compares the displayed price 
quotes and enters a selection at the user terminal 22, 24, or 26 for one of the price quotes received from one of 
tiie dealing systems 10, 12, or 14 of one of the financial institutions 4, 6, or 8. At S6, the user terminal 22, 24, 
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or 26 automatically sends the selection over the network 28 to the selected financial institution dealing system 1 0, 
12, or 14. At S7, the selected financial institution dealing system 10, 12, or 14 receives the selection, and if the 
selection is received within a predetermined time-out period, the selected dealing system 10, 12, or 14 
automatically reviews the currency exchange transaction against predefined parameters for the user and automatically 
sends a confirmation of acceptance of the selection over the network 28 to the user 16, 18, or 20 at the user 
terminal 22, 24, or 28. The selected dealing system 10, 12, or 14 also automatically hands off the selection to the 
deal capture system 36, 38, or 40 of the selected dealing system 10, 12, or 14 for settiement and optionally hands off 
the settied transaction to a matching application 42. 

[0054] In an embodiment of the present invention, the client/server security system provides end-to-end 
encryption using, for example, 56-bit DES or RC4. To authenticate the end user to the system, the security system 
performs a mutual challenge/response authentication for each session that Is created. Mutual challenge response is a 
high-security form of secret-key based authentication, in which each party sends the other a random number, which 
the other part/ returns encrypted under a secret key known to both parties. By independentiy performing the same 
encryption at both ends, the identity of the other party may be conclusively determined. 

[0055] An aspect of an embodiment of the present invention is the high performance of the challenge/response 
approach of the security system employed. Unlike public key authentication techniques, it is computationally 
inexpensive, while remaining as, or more, secure. Public key based authentication also takes longer to compute in 
real-time. The challenge/response technique employed by a security system, such as SmartGate, requires only 
approximately one millisecond. 

[0056] In an embodiment of the present invention, effectively, the challenge/response technique is limited by 
the bandwidth of the network connection, unlike the pure public key approach, which is Central Processing Unit (CPU) 
limited. A typical Secure Sockets Layer (SSL) based application can support about twenty active users on a single 
SPARC20 Scalable Processor Architecture microprocessor before performance lags become extreme. A Pentium- 
based firewall, such as SmartWall firewall available from V-One Corporation and using the authentication approach 
from V-One corporation, can support more than three hundred simultaneous users. 

[0057] It is reported customers' foreign exchange buying behavior currently bodes well for the system for an 
embodiment of the present invention that offers multiple bank prices simultaneously. In particular, a significant 
proportion of customers require multiple quotes to execute transactions over specific amounts. The vast majority of 
these customers have corporate policies that require competitive quotations in order to trade. Market expectations 
for a multibank electronic foreign exchange execution system for an embodiment of the present invention and its 
chances for success are outstanding, in view of the competitive and very fluid environment within which foreign 
exchange currentiy finds itself. 

[0058] An aspect of an embodiment of the present invention, for example, is a pilot for a multibank foreign 
exchange trading capability for the commercial marketplace and, more specifically, for corporations and fund 
managers. This path enables distribution of additional proprietary products as well. In this aspect, a strategy is 
to organize a small group of price makers to participate and initially target large fund manager and corporate 
customers. The major benefit of such a service is instantaneous access to simultaneous, multi-sourced competitive 
prices for execution. 

[0059] Another aspect of an embodiment of the present invention, for example, is a service in which member banks 
each own, operate, and maintain a system capable of providing rate quotation and trade execution functions in a 
reliable, secure and consistent manner. A service provider, which can be, for example, a subsidiary of a financial 
institution, such as a bank, coordinates the collective operation of these individual systems on behalf of the 
customer base. The client users are provided with a message-based solution which is capable of communicating 
independentiy with each member bank's system using strong authentication and encryption technology. Member banks 
have no knowledge of quotes or trades of the other banks. 

[0060] , In an embodiment of the present invention, the service providing entity is uniquely positioned to offer a 
complete "value chain product' combining multibank electronic execution with multibank confirmation and settiement, 
referred to as foreign exchange match. An embodiment of the present invention involves, for example, embedding a 
high-level technology service within the customer's own environment and empowering the customer to seek as well as 
act on competitive, compliant rates that minimize the customer's own financial and operational risk. 
[0061] The introduction of multibank foreign exchange for an embodiment of the present invention provides 
customers with a more cost effective, efficient way to obtain competitive quotes for foreign exchange transactions. The 
client seeks the most efficient way to price discovery, and the multibank foreign exchange trading system 2 provides 
clients vyrth a "one stop" solution. Typically, the average company that trades foreign exchanges uses, for example, 
ten banks for this activity, with perhaps three-fourths of its volume executed with three of these counterparties. 
In the commercial foreign exchange market, securing multiple price quotes is a matter of custom, policy, and/or 
regulation. 

[0062] Further, in the corporate sector, price outweighs all other service considerations, and customers are 
often compelled by corporate compliance policies to obtain multiple quotes. In the financial institution sector, it 
is commonly known that regional banks require multiple bank prices to create their own price. For fund managers, 
ERISA regulations require, for example, that investment managers provide their clients with "best execution." This 
means. that they must prove for every trade that they received the best price available for a given amount at the 
time of execution. The method and system for an embodiment of the present invention automates the time consuming 
process of obtaining prescribed multiple quotes from bank counterparties by phone. 

[0063] Advantages to clients of the method and system for an embodiment of the present invention include, for 
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example, electronic trading on a standing price and nondiscriminatory price presentation. In other words, the system 
presents the prices as the quotes are received, such that one bank does not hold back another, and rate time-outs 
are handled independently. Another advantage to the clients is flexibility of installation, for example, in that 
network configurations are varied, and GUIs coexist with other PC applications on multi-use terminals/PCs. 
[0064] The method and system for an embodiment of the present invention also provides, for example, a defensive 
measure to counter the current practice of clients shopping the rates. It is certain that the client drives the 
choice as to with which bank to trade. For example, price feeds are not a significant differentiating factor to help 
clients choose, as they are practically 'cookie cuf with the same tight spreads. An additional advantage of the method 
and system for an embodiment of the present invention Is flexibility in implementation. For example, participating 
banks implement their own pricing algorithms, extract their own spreads, and impose different trading limits and 
controls on users based on their own internal criteria. 

[0065] A further advantage of the method and system for an embodiment of the present invention is impartiality 
in implementation. Specifically, an embodiment of the present invention enables a non-centralized approach that does 
not require a bank's data to be off-premises. In addition, an embodiment of the present invention leverages current 
systems and technology, in that all deal capture processes remain intact Irrespective of proprietary trading or 
multibank trading system execution. 

[0066] Overarching these individual advantages and benefits of the method and system for an embodiment of the 
present invention are certain system design characteristics that weigh in favorably from both a participating bank's 
perspective as well as a customer's perspective. Such characteristics include, for example, state-of-the-art 
security, use of new hardware and software standards, as well as speedy throughput/performance. In an embodiment of 
the present invention, the service providing subsidiary of the financial institution positions Itself as the third- 
party intermediary in a multibank environment. An embodiment of the present invention facilitates financial 
transactions between counterparties, collecting fees from both participants in each transaction. 
[0067] The concept of a multibank trading system for an embodiment of the present invention at once implies the 
creation of a level playing field amongst participating banks for certain transactions, such as currency pairs. An 
embodiment of the present invention allows the creation of a sense of a trading 'club' with an elite membership, 
allowing each member to enter with its own product and its own customer base intact. The participating banks' 
individual trading systems remain valid. This approach allows the financial institution to build premium value, for 
example, through order book, embedded price, and end-to-end processing. 

[0068] In an embodiment of the present invention, linking to multiple banks remains a client's choice, for 
example, to facilitate compliance with rules of best execution and the like. In a multibank scenario for an 
embodiment of the present invention, the financial institution's price is automatically given to contracted 
customers, whereas the financial institution might not otherwise be among the banks called over the telephone for 
(competitive) quotes. Increased trade volume thus outweighs any perceived awkwardness. Typically, transactions not 
exceeding a predetermined transaction amount are targeted for multibank electronic execution. 
[0069] Undertaking the multibank initiative for an embodiment of the present invention involves, for example, 
leveraging existing development initiatives, such as use of the re-platforming of a banks' foreign exchange dealing 
system to full client-server architecture to lay the foundation for a multibank service. Such an initiative also 
involves, for example, obtaining bank participation, such as assembling a small group of price makers to form the 
foundation for early membership. It also involves, for example, initiating trading through a pilot, such as 
commencing trading between the initial customers and participating banks, on a limited hour trading basis, if 
necessary. Customers can be solicited, for example, as referrals from the participating banks. They may or may not 
be current users of a bank's proprietary electronic trading system. Final^, such an initiative involves, for 
example, expanding the sales effort beyond the initial pilot users and across all regions. 

[0070] As a by-product to the multibank trading system for an embodiment of the present invention, a 
complementary bank market for the financial institution's executable price can be developed, since many other banks 
may be neither technologically ready to compete nor ready to make the required investment for either stand-alone 
electronic execution or multibank participation. An aspect of an embodiment of the present invention is a 
proprietary banking model, which is a stand-alone version of a foreign exchange dealing system available with or 
without the financial institution feed, provided to establish experience with running multiple versions of the 
foreign exchange dealing system. The financial institution can stake out the entire price risk associated with quoting 
currencies, or at the client's discretion, only that portion of the currency roster that the client is not in a position to 
cover. 

[0071] In an embodiment of the present invention, the secure network becomes a fixed asset of the system. As 
such, it can be leveraged when posing alternatives to banks considering participation. It is very attractive to 
consider use of the network to carry any single bank's system. The option to connect to additional banks, for 
example, can be initiated only at a customer's request, such as when the customer needs to be compliant with 
multiple quote requirements. The investment on the part of a bank which does not yet have its own electronic trading 
system is streamlined considerably. The sen/ice providing subsidiary of the financial institution can offer such a 
bank a system as v\/ell as the necessary networking to support advanced, secure communications. Branching out to 
participate in a multibank scheme may or may not be desirable, but not at the cost of Its own single-bank 
Initiative. Selling, supporting, and managing proprietary systems can be in addition to the sennce providing 
subsidiai/s main focus of multibank execution. 

[0072] Various preferred embodiments have been described In fulfillment of the various objects of the invention. 
It should be recognized that these embodiments are merely illustrative of the principles of the Invention. Numerous 
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modifications and adaptations thereof will be readily apparent to those skilled in the art without departing from 
the spirit and scope of the present invention. Accordingly, the invention is only limited ty the follov^nng claims. 

Claims 

I. A method for performing a currency exchange transaction between a user and a participating financial institution, 
comprising: 

receiving a request for a price quote for the currency exchange transaction for the user; 

automatically sending the request for price quote simultaneously to a currency exchange dealing system of 
each of a plurality of participating financial institutions; 

automatically returning the requested price quote from each of the currency exchange dealing systems for ttie 
user 

automatically displaying the returned price quote of each of the currency exchange dealing systems for the 
user; 

receiving a selection for the user of the displayed price quote of at least one of the currency exchange 
dealing systems; 

automatically sending the selection to the at least one currency exchange dealing system for the user; and 
automatically confirming the selection for the user by the at least one currency exchange dealing system. 

Z The method of claim 1, wherein receiving the request further comprises receiving the request at a computer 
terminal. 

3. The method of claim 2, wherein receiving the request at the computer terminal further comprises receiving the 
request on a user interface at the computer terminal. 

4. The method of claim 3, wherein receiving the request on the user interface further comprises receiving the 
request on one of a graphical user interface and a computer user interface at the computer terminal. 

5. The method of claim 1, wherein receiving the request further comprises receiving a selection of at least one 
parameter for the currency exchange transaction selected from a group of parameters consisting of spot, fonward 
and swap. 

6. The method of claim 5, wherein receiving the request further comprises receiving a selection to get a quote for 
the currency exchange transaction according to the parameter selection. 

7. The method of daim 1, wherein automatically sending the request further comprises automatically sending the 
request from a computer terminal. 

8. The method of claim 7, wherein automatically sending the request from the computer terminal further comprises 
automatically authenticating the user by a security application on the computer terminal. 

9. The method of claim 7, wherein automatically sending the request from the computer terminal further comprises 
automatically sending the request by a user interface on the computer terminal. 

10. The method of claim 9, wherein automatically sending the request by the user interface further comprises 
preconfiguring the user interface with information about each of the plurality of participating financial institutions. 

II. The method of claim 10, wherein preconfiguring the user interi'ace further comprises preconfiguring the user 
interface with a network address and security details for each of the plurality of participating financial institutions. 

12. The method of claim 7, wherein automatically sending the request further comprises automatically sending the 
request from the computer terminal over a network. 

13. The method of claim 12, wherein automatically sending the request over the network fiirther comprises 
automatically sending the request over a secure network. 

14. The method of claim 12, wherein automatically sending the request over the network further comprises 
automatically sending the request over a virtual private network. 
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15. The method of claim 12, wherein automatically sending the request over the network further comprises 
automatically sending the request over a connection to the network selected from a group of connections 
consisting of a dial-up. an integrated services digital network, and a dedicated line. 

16. The method of claim 1, wherein automatically returning the requested price quote further comprises 
automatically returning the requested price quote from a repository of price quotes of each of the currency 
exchange dealing systems. 

17. The method of claim 16, wherein automatically returning the requested price quote from the repository of price 
quotes further comprises automatically storing price quotes in a table of the repository of each of the currency 
exchange dealing systems. 

18. The method of claim 17, wherein automatically storing the current price quotes further comprises receiving a 
feed of price quotes by each of the currency exchange dealing systems. 

19. The method of claim 1, wherein automatically returning the requested price quote further comprises 
automatically returning the price quote to a computer terminal for the user. 

20. The method of claim 19, wherein automatically returning the price quote to the computer terminal further 
comprises automatically returning the price quote to a user interface on the computer terminal. 

21. The method of daim 19, wherein automatically returning the price quote to the computer terminal further 
comprises automatically returning the price quote to the computer terminal over a network. 

22. The method of claim 21, wherein automatically returning the price quote over the network further comprises 
automatically returning the price quote over a secure network. 

23. The method of claim 21, wherein automatically returning the price quote over the network further comprises 
automatically returning the price quote over a virtual private network. 

24. The method of claim 1, wherein automatically displaying the price quote further comprises automatically 
displaying the price quote of each of the currency exchange dealing systems at a computer terminal. 

25. The method of claim 24, wherein automatically displaying the price quote further comprises automatically 
displaying the price quote of each of the currency exchange dealing systems on a user interface at the computer 



26. The method of claim 24, wherein automatically displaying the price quote further comprises automatically 
displaying the price quote as returned by each of the currency exchange dealing systems for real-time comparison 
by the user. 

27. The method of claim 1, wherein receiving the selection further comprises receiving the selection at a computer 
terminal. 

28. The method of claim 27, wherein receiving the selection at the computer terminal further comprises receiving 
the selection on a user interface at the computer terminal. 

29. The method of claim 1, wherein automatically sending the selection further comprises automatically sending the 
selection from a computer terminal. 

30. The method of claim 29, wherein automatically sending the selection from the computer terminal further 
comprises automatically sending the selection by a user interface on the computer terminal. 

31. The method of claim 29, wherein automatically sending the selection from the computer terminal further 
comprises automatically sending the selection over a network. 

32. The method of claim 31, wherein automatically sending the selection over the network further comprises 
automatically sending the selection over a secure network. 

33. The method of claim 31. wherein automatically sending the selection over the network further comprises 
automatically sending the selection over a virtual private ne1wori<. 

34. The method of claim 1, wherein automatically confirming the selection further comprises automatically 
confirming the selection, if the selection is received by the at least one currency exchange dealing system 
within a predetermined period of time after returning the requested price quote by the at least one currency 
^change dealing system for the user. 
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35. The method of claim 1, wherein automaticaily confirming the selection further comprises automatically reviewing 
the selection against at least one predefined parameter for the user selected from a group of parameters 
consisting of a credit allocation for the user, a maximum transaction size for the user, and a delivery limit for 
the user. 

36. The method of claim 1 , wherein automatically confirming the selection further comprises automatically sending 
the confirmation to a computer terminal for the user. 

37. The method of claim 36, wherein automatically sending the confirmation to the computer terminal further 
comprises automatically sending the confirmation to a user interface on the computer terminal. 

38. The method of claim 36, wherein automatically sending the confirmation to the computer terminal further 
comprises automatically sending the confirmation to the computer terminal over a network. 

39. The method of claim 38, wherein automatically sending the confirmation over the network further comprises 
automatically sending the confirmation over a secure network. 

40. The method of claim 38, wherein automatically sending the confirmation over the network further comprises 
automatically sending the confirmation over a virtual private network. 

41. The method of claim 1, further comprising automatically handing off the selection by the at least one currency 
exchange dealing system for settlement of the currency exchange transaction with the user. 

42. The method of claim 41, wherein automatically handing off the selection for settlement further comprises 
automatically handing off the selection to a deal capture system of the at least one currency exchange dealing 
system for settlement of the currency exchange transaction with the user. 

43. The method of claim 42, wherein automatically handing off the selection for settiement further comprises 
automatically handing off the settled currency exchange transaction for a match between the user and the at least 
one currency exchange dealing system. 

44. The method of claim 43, wherein automatically handing off the settied transaction further comprises 
automatically handing off the settled currency exchange transaction to a match application for the match. 

45. The method of claim 44, wherein automatically handing off the settled transaction to the match application 
further comprises automatically handing ott the settled transaction to the match application over a network. 

46. A system for performing a currency exchange transaction between a user and a participating financial 
institution, comprising: 

means for receiving a request for a price quote for the currency exchange transaction for the user; 

means cooperating with the receiving means for automatically sending the request for price quote 
simultaneously to a currency exchange dealing system of each of a plurality of participating financial 
institutions; 

means coupled to the receiving means for automatically returning the requested price quote from each of the 
cun-ency exchange dealing systems for the user; 

means coupled to the returning means for automatically displaying the returned price quote of each of the 
currency exchange dealing systems for the user; 

means cooperating with the displaying means for receiving a selection for the user of the displayed price 
quote of at least one of the currency exchange dealing systems; 

means cooperating with the displaying means for automatically sending the selection to the at least one 
currency exchange dealing system for the user; and 

means coupled to the selection sending means for automatically confirming the selection for the user by the 
at least one currency exchange dealing system. 

47. The system of claim 46, wherein the means for receiving the request further comprises a computer terminal. 

48. The system of claim 47, wherein the computer temninal further comprises a user interface of the computer 
terminal. 
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49. The system of claim 48, wherein the user interface further comprises one of a graphical user Interface and a 
computer user interface. 

50. The system of claim 46, wherein the means for automatically sending the request further comprises a computer 
terminal having a security application for authenticating the user. 

51. The system of claim 46, wherein the means for automatically sending the request further comprises a computer 
terminal having a user Interface preconfigured with Information about each of the plurality of financial institutions. 

52. The system of claim 51, wherein the information about each of the plurality of financial institutions further 
comprises a network address and security details for each of the participating financial institutions. 

53. The system of claim 46, wherein the means for automatically sending the request further comprises a computer 
terminal coupled to a networl<. 

54. The system of claim 53, wherein the networic further comprises a secure network. 

55. The system of claim 53, wherein the network further comprises a virtual private network. 

56. The system of claim 46, wherein the means for automatically sending the request further comprises a computer 
terminal coupled to a network over a connection selected from a group of connections consisting of a dial-up, an 
integrated sen/lces digital network, and a dedicated line. 

57. The system of claim 46, wherein the means for automatically returning the requested price quote further 
comprises a repository of price quotes of each of the currency exchange dealing systems. 

58. The system of claim 46, wherein the means for automatically returning the requested price quote further 
comprises each currency exchange dealing system coupled over a network to a computer terminal. 

59. The system of claim 58, wherein the network further comprises a secure network. 

60. The system of claim 58, wherein the network further comprises a virtual private network. 

61. The system of claim 46, wherein the means for automatically displaying further comprises a computer terminal. 

62. The system of claim 61, wherein the means for automatically displaying further comprises a user Interface of 
the computer terminal. 

63. The system of claim 46, wherein the means for receiving ttie selection further comprises a computer terminal. 

64. The system of claim 63, wherein the means for receiving the selection further comprises a user interface of the 
computer terminal. 

65. The system of claim 46, wherein the means for automatically sending the selection further comprises a user 
interface of the computer terminal coupled to the at least one currency exchange dealing system over a network. 

66. The system of claim 65, wherein the network further comprises a secure network. 

67. The system of claim 65, wherein the network further comprises a virtual private network. 

68. The system of claim 46, wherein the means for automatically confirming the selection further comprises the at 
least one currency exchange dealing system coupled over a network to a computer terminal. 

69. The system of claim 46, further comprising means for automatically handing off the selection by the at least 
one currency exchange dealing system for settlement of the currency exchange transaction with the user. 

70. The system of claim 69, wherein the means for automatically handing off the selection for settlement further 
comprises a deal capture system of the at least one currency exchange dealing system. 

71. The system of claim 69, wherein the means for automatically handing off the selection for settlement further 
comprises means for automatically matching the settled transaction between the currency exchange dealing system 
and the user. 

72. The system of claim 71, wherein the means for automatically matching the settled transaction further comprises 
a match application coupled to the at least one currency exchange dealing system over a network. 
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(57) An automated trading system makes use of 
various components, such as one or more transaction 
servers (6, 202) and one or more rate sen/ers (8, 204) 
and a number of terminals (2, 210; 4, 102, 104). A 
request for a proposed transaction for a user (12, 116, 
208) is entered at either a user's terminal (2, 210) or 
a sales trader's terminal (4, 102, 104) and sent to a 
transaction server (6, 202) coupled to a rate server (8, 
204). If a first predefined condition for generating an 
executable rate quote Is identified, an executable rate 
quote is generated by the rate server (8, 204) and sent 
back to the user's (2, 210) or sales trader's terminal 
(4, 102, 104) for the user (12, 116, 208). Otherwise, 
if a second predefined, condition for a category 
trader's rate quote is identified, a request for the 
category trader's rate quote is sent by the transaction 
server (6, 202) to one or more category trader's 
terminals, prompting entry of a category trader's rate 
quote by one or more of the category traders, which is 
likevwse sent back to the user's (2, 210) or sales 



trader's terminal (4, 102, 104) for the user (12, 116, 
208). If a request for execution is entered at the 
user's (2, 210) or sales trader's terminal (4, 102, 104) 
within a predetermined period of time, the transaction 
server (6, 202) hands off the request for execution to 
a hand-off sen/er (7, 108, 206), which executes the 
transaction for the user (1 2, 11 6. 208). 
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Cross Reference to Related Applications 

[0001] This application is a continuation-in-part of U.S. Serial No. 08/836,713, filed May 13, 1997, which 
* claims priority to applicants' PCT application no. PCT/EP96/03972, filed September 10, 1996, and which claims 
priority to applicants' EPO application no. 95114467.4, filed Septemt)er 14, 1995. This application claims priority 
to applicants' co-pending applications Serial No. 60/111,030 filed December 4. 1998; Serial No. 60/111,031 filed 
December 4, 1998; and Serial No. 60/1 11,032 filed December 4, 1998. 

io Field of the Invention 

[0002] The present invention relates to a computer system for data management and method for operation of the 
system, and more particulariy to an automated warrant trading system. 

Background of the Invention 

15 

[0003] In the past, the trading of warrants was time consuming and cost intensive, because it was necessary for 
a customer in a financial institution, such as a bank, to search by telephone or in publications to locate the best 
warrant for a consumer. If the consumer wished to purchase warrants, it was necessary for the consumer to first 
contact his or her local bank which could process the order through a stock exchange or by placing a call to a 
warrant market maker. Since an on-line information and trading system about traded warrants with executable prices 

2" did not exist, the customer in the local bank was not able to provide the consumer with actual on-line information. 
Hence, there existed a time difFerential between the placing of a buy/sell order by the customer and its 
implementation, resulting in a risk of exchange and/or price fluctuations during that time difference. 
[0004] It was often the case that the implementation of the buy/sell order was based on a limit oriented on the 
rates of tiie previous day, since the order could not be implemented on the same day. The reasons for the time delay 

25 were either that the order was placed a number of hours before it was executed at the stock exchange or that the 
trading room telephones of the market maker were often busy during hectic market times. Therefore, local banks often 
placed blind orders at unknown prices for consumers and did not receive immediate deal confirmations. 
[0005] The invention disclosed in co-pending U.S. Pat. Application Ser. No. 08/836,713 (referred to herein as 
"the CATS-OS system" or "the existing CATS-OS system" and incorporated herein by this reference) addresses those 
problems and provides a computer system for data management and a method for operating the system for the bank, 

30 which realizes a data management providing instantaneous data with an improved accuracy and a reduced error 
probability when processing data transactions, combined with a high level of security. The eMsting CATS-OS system 
includes use of a client-sen/er architecture, which has a number of servers, such as a transaction server, a rate 
server, a hand-off server, a credit server, and a security server. In a typical interaction with the CATS-OS system, 
the customer or other user of the system connects to the system and is authenticated by a security manager, which 
allows the user certain privileges depending on the level of user, such as customer, trader, and administrator levels. 

35 [0006] In the existing CATS-OS system, a customer normally is allowed to view rates, execute transactions, view 
those transactions, print reports against transactions conducted, and view -positions. A trader is allowed to 
manually input rates if desired, although this not a normal trader function. Normal trader functions include 
maintaining instruments as new instruments become avaOable and old instruments expire, generally maintaining the 
system, maintaining volumes, maintaining the credits, and maintaining the users themselves. The main rate and sales 

^ information is input automatically from customer systems. Customers typically have various systems that calculate 
the prices of warrants. The CATS-OS system essentially receives all of the rates information that comes from customer 
systems, which may be three or four million updates a day, inputs this information into a separate rate sewer arid 
then holds this information so that it is available for the customers to deal against. 

[0007] Currentiy, the CATS-OS system, which primarily deals with warrants and equities, functions on a standing 
price basis, in which the host bank for the system issues a price that the bank guarantees for a certain number of 
45 seconds. This guarantee allows the users of the CATS-OS system to deal at the price issued. However, in order to 
limit the risk to the host bank, the host bank typically only authorizes deals up to a certain size at the standing 
price. Thus, a problem with the existing CATS-OS system is that users may need to perform deals that exceed the host 
bank's allowable deal size. 

[0008] In addition, the existing CATS-OS system requires a certain amount of technology and equipment to be 
available at the customer's or other user's site. This technology and equipment can include a personal computer (PC) 

^ and the capability to communicate data. Not all customers or other potential users of the CATS-OS system wnsh to 
have these capabilities installed, and instead prefer to deal wrtth warrant trading on the telephone by directiy 
speaking to a trader. This preference directiy conflicts with the purpose of the CATS-OS system, which is intended 
to avoid the situation of customers directiy speaking to traders for what are typically smaller sized trades. 
[0009] Further, while the existing CATS-OS system provides an effective automated electronic trading tool for 

55 bank customers and consumers for a single bank, the system displays the process of only one bank. The customers are 
primarily brokers, so the bank is often unaware of the identity of the actual consumer. Currentiy, it is not 
possible, for example, for a plurality of banks to add prices to the CATS-OS system in order to allow brokers to buy 
and sell warrants of other banks for consumers while dealing with only a single system. 
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Summary of the Invention 

[0010] It is a feature and advantage of the present invention to provide an automated trading system and method 
which allovt/s deals to be consummated that exceed limits imposed, for example, by the host bank, as well as in other 
^ circumstances in which a rate may not be available. 

[0011] It is a further feature and advantage of the present invention to provide an automated trading system and 
method which allows a trader to respond to a request for a quote and to provide a proposed price against which a 
user can trade. 

[0012] It is another feature and advantage of the present invention to provide an automated trading system and 
10 method which allows a special type of trader, referred to as a sales trader, to deal on behalf of selected customers 
within the trading system, without necessarily knowing the price of particular warrants and without setting their 
own prices. 

[0013] It is an additional feature and advantage of the present invention to provide an automated trading system 
and method which affords all the advantages of the system, such as reduced error rates, without the expense 
associated with actually installing the system. 

[0014] It is another feature and advantage of the present invention to provide an automated trading system and 
method which enables selected customers to deal over the telephone and avoids the necessity for such customers to 
install the system. 

[001 5] It is a further feature and advantage of the present invention to provide an automated trading system and 
method which enables full warrant trading capabilities v/ithout the expense of highly paid professional traders. 
20 [0016] It is an additional feature and advantage of the present invention to provide an automated trading system 
and method which enables users to easily buy and sell warrants from a plurality of banks and market makers. 
[0017] It is a further feature and advantage of the present invention to provide an automated trading system and 
method that avoids the need for users of the system of one bank who access the system by dial-up having to 
disconnect and redial with another bank. 

[0018] It Is another feature and advantage of the present invention to provide an automated trading system and 
method which avoids the necessity for a user having to log in separately to a plurality of systems. 
[0019] It is an additional feature and advantage of the present invention to provide an automated trading system 
and method that avoids integrating the system to the extent that the system may be considered and regulated as a 
stock exchange. 

[0020] It is another feature and advantage of the present invention to provide an automated trading system and 
30 method that maintains segregation between price makers. 

[0021] To achieve the stated and other features, advantages and objects, an embodiment of the present invention 
provides an automated system and method for warrant trading which includes various aspects, such as a request for 
quote aspect, a sales trader aspect, and a multi-bank aspect. The method and system for an embodiment of the present 
invention makes use, for example, of various servers, such as a transaction server, a rate server, a hand-off server, 
a credit server, and a security server. 

[0022] The request for quote aspect for an embodiment of the present invention makes use in particular, for 
example, of a user terminal, category trader terminals, the transaction server, the rate server, and a mail server. 
The sales trader aspect for an embodiment of the present invention makes use in particular, for example, of one or 
more sales trader terminals, the transaction server, the credit sen/er, the hand-off server, and the credit server. 
The multi-bank aspect for an embodiment of the present invention makes use in particular, for example, of the user 
40 terminal, as well as the transaction servers, rate servers, and hand-off servers of a plurality of independentiy 
maintained and segregated trading systems. 

[0023] In an embodiment of the present invention, a request for the user for a proposed financial transaction, 
such as a warrants trade, is received at a terminal, such as the user terminal or the sales trader terminal. The 
request can be received at the user terminal by the user directly inputting the request at the user terminal. 
Alternatively, the request is communicated, for example, by telephone, fax or e-mail by the user to a sales trader 
^ and is received at the sales trader terminal by the sales trader inputting the request for the user at the sales 
trader terminal. 

[0024] In turn, in an embodiment of the present invention, the request is received from the terminal by a 
transaction server coupled to the terminal and by a rate sen/er coupled to the transaction server. In the mutti-bank 
aspect, the request is received from the terminal by the transaction servers of each of the plurality of 
„ independently maintained and segregated trading systems coupled to the terminal and by the corresponding rate server 
coupled to the transaction sen/ers of each of the trading systems. 

[0025] In an embodiment of the present invention, a rate quote is generated by the system, which consists of 
either an executable rate quote or a category trader's rate quote for the proposed financial transaction. The 
executable rate quote is automatically generated by the rate sen/er, if a first predefined condition for generating 
the executable rate quote is identified by the transaction sen/er or the rate server coupled to the transaction 
55 sen/er. In the multi-bank aspect, the executable rate quote is automatically generated by the rate sen/er of at 
least one of the plurality of trading systems coupled to the corresponding transaction server of the particular 
trading system, if the first predefined condition for generating the executable rate quote is identified by either 
the rate sen/er or the transaction sen/er of the particular trading system. 
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[0026] In an embodiment of the present invention, the first predefined condition for automatically generating 
the executable rate quote exists if a predefined cause for rejection of the proposed transaction, such as the 
transaction counterparty is suspended, the proposed transaction system is suspended, the proposed transaction 
instrument is suspended, the proposed transaction rate is suspended, the proposed transaction exceeds the available 
volume, or the proposed transaction amount exceeds a predefined limit, is not identified by either the transaction 
5 server or the rate server. 

[0027] In an embodiment of the present invention, if the first predefined condition for automatically generating 
the executable rate quote is not identified, then the category trader's rate quote is generated if a second 
predefined condition for generating the category trader's rate quote is identified. The second predefined condition 
for generating the category trader's rate quote exists if one or more of the predefined causes for rejection of the 
proposed financial transaction is identified by either or both of the transaction sen/er or the rate sen/er coupled to 
the transaction server and if a predetermined selling of a request for quote parameter corresponding to the one or 
more identified cause or causes for rejection is likewise confirmed by one or both of the transaction server or the 
rate server. 

[0028] In an embodiment of the present invention, If the second predefined condition for generating a category 
trader's rate quote is Identified, the transaction sen/er automatically generates a request for a category trader's 
15 rate quote, which is automatically communicated by the transaction sen/er via a mail server to one or more category 
trader's terminals. One or more of the category traders is prompted by a display on the category trader's terminal 
for entry of the category trader's rate quote, and at least one of the category traders can then enter the category 
trader's rate quote at the category trader's terminal, which is communicated by the trader's terminal to the 
transaction server. 

[0029] In an embodiment of the present invention, the transaction server sends either the executable rate quote 
^ or the category trader's rate quote to the user's terminal, or in the sales trader aspect, to the sales trader 
terminal for the user, where the rate quote is automatically displayed for the user. At the same time, a system 
counter is automatically set for a predetermined period of time, which holds the generated rate quote for the user 
for the predetermined time period and, in effect, guarantees the rate quote for the predetermined time period for 
the user. 

25 [0030] If a request for execution of the proposed transaction for the user is received at the user's terminal, 
or in the sales trader aspect, at the sales trader's terminal, within the predetermined period of time, the request 
for execution is automatically sent to the transaction server coupled to the terminal. In the multi-bank aspect, the 
request for execution is automatically sent to the transaction server of one of the plurality of trading systems. In 
either case, the request for execution is automatically handed off to a hand-off server coupled to the transaction 
server, and the hand-off server automatically executes the proposed transaction for the user. 

30 [0031] Additional objects, advantages and novel features of the invention will be set forth in part in the 
description which follows, and in part will become more apparent to those skilled in the art upon examination of the 
following, or may be learned by practice of the invention. 

Brief Description of the Drawings 

35 [0032] 

Fig. 1 is a schematic diagram which illustrates an example overview of key components and the flow of 
information between the key components of a request for quote aspect of an embodiment of the present invention; 

^ Fig. 2 is a sample category maintenance screen for the request for quote aspect of an embodiment of the present 

invention; 

Fig. 3 shows a sample deal entry screen for the request for quote aspect of an embodiment of the present 
invention; 

45 Fig. 4 shows a sample message box for the request for quote aspect of an embodiment of the present invention; 

Fig. 5 shows a sample trade details screen for the request for quote aspect of an embodiment of the present 
Invention; 

Fig. 6 is a flow chart which illustrates an example of the process of the customer requesting a rate in the 
^ request of quote aspect of an embodiment of the present invention; 

Fig. 7 is a flow chart which illustrates an example of the request for quote notification process for the 
request for quote aspect of an embodiment of the present Invention; 

^ Fig. 8 Is a schematic diagram which illustrates an ovennew example of key components and the flow of 

Information between the key components In a sales trader aspect of an embodiment of the present Invention; 



Fig. 9 is a schematic diagram which illustrates an example ovennew of databases for the sales trader aspect of 
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an embodiment of the present invention: 



Fig. 10 is a schematic diagram which amplifies and provides further detail regarding the sample database 
overview shown in Fig. 9; 

Fig. 1 1 shows a sample deal entry screen for the sales trader aspect of an embodiment of the present invention; 

Fig. 12 shows a sample transaction screen for the sales trader aspect of an embodiment of the present invention; 

Fig. 13 shows a sample branch maintenance screen for the sales trader aspect of an embodiment of the present 
invention; 

Fig. 14 shows a sample customer maintenance screen for the sales trader aspect of an embodiment of the present 
invention; 

Fig. 15 showre a sample trade details screen for the sales trader aspect of an embodiment of the present invention; 

Fig. 16 is a flow chart which illustrates an example of the sales trader transaction process for the sales 
trader aspect of an embodiment of the present invention; 

Fig. 17 is a schematic diagram which illustrates an overview example of key components and the flow of 
information between the key components for a multi-bank aspect of an embodiment of the present invention; and 

Fig. 18 Is a flow chart which illustrates an example of the process of a customer transaction in the multi-bank 
aspect of an embodiment of the present invention. 

Detailed Description 

[0033] Referring now In detail to an embodiment of the invention, an example of which is illustrated in the 
accompanying drawings, a request for quote aspect of an embodiment of the present invention provides an automated 
system and method for warrant trading which allows deals to be consummated that exceed the limits allowed by the 
host bank and in other circumstances in which a rate may not be available. To accomplish this function, an 
embodiment of the present invention allows a trader to respond to a request for a quote and to provide a proposed 
price against which the user can trade. The system and method of an embodiment of the present invention performs the 
request for quote function, which was not previously possible, in connection wXh the existing CATS-OS system. 
[0034] Fig. 1 Is a schematic diagram which illustrates an example overview of key components and the flow of 
information between key components of the request for quote aspect for and embodiment of the present invention. The 
request for quote aspect makes use, for example, of a graphical user interface (GUI), including a customer GUI 2 and 
a trader GUI 4. The request for quote aspect also utilizes a warrants transaction server (WTS) 6, a warrants rate 
server (WRS) 8, and a mail server (MAI) 10. The request for quote aspect is, activated when a user, such as a 
customer 12 at the customer GUI 2, attempts to conduct a deal as normal within the CATS-OS system, but is prevented 
for some reason specific to the existing CATS-OS system, such as the maximum transaction size being exceeded. A 
message regarding the attempted deal is routed to a trader 14 at the trader GUI 4. The trader 14 views information 
about the deal, which allows the trader 14 to monitor the deal and to input a proposed price manually, based on 
criteria provided in the customer's attempt. The manually input information is then transmitted to the customer 12, 
who has the opportunity to accept or decline the proposed deal. 

[0035] Thus, the request for quote aspect for an embodiment of the present invention includes essentially an 
electronically messaged conversation between the customer 12 at the customer GUI 2 and the trader 14 at the trader 
GUI 4, providing an extension of the existing CATS-OS system under certain circumstances, a principle one of which 
is that the attempted deal is larger than the host bank is willing to handle at the standing price. To accomplish 
this electronic messaging, an embodiment of the present invention provides additional messaging capability to 
existing CATS-OS system messages. In particular, an embodiment of the present invention includes a system and 
method for providing messages directly between the customer GU1 12 and the trader GUI 4. The trader 14 at the trader 
GUI 4 views a pop-up message when the customer 12 at the customer GUI 2 wishes to perform a rate that would not 
otherwise be allowed, and the trader 14 then responds accordingly, for example, by inputting a proposed price. 
[0036] The request for quote aspect for an embodiment of the present invention improves the usability of the 
existing CATS-OS system by allowing the trader 14 to quote rates for all instruments for which the trader 14 is 
responsible. The trader 14 is kept permanentiy informed of the warrant transactions that are being rejected, and the 
trader 14 is given the power to override the rejected transactions. The request for quote mechanism is useful where 
the CATS-OS system is unable to quote an executable rate automatically. It is also useful for executing transactions 
that would otherwise be rejected due to certain request for quote triggers or parameters. For every warrant deal 
transaction that would otherwise be rejected, an embodiment of the present invention makes it possible for the 
trader 14 to override the request for quote triggers. The trader 14 also has the ability to quote a rate to the 
customer 12 for the above circumstances. These request for quote notifications go only to the traders who are 
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responsible for the instruments specified in the warrants transactions. 

[0037] Fig. 2 is a sample category maintenance screen 16 for the request for quote aspect of an embodiment of 
the present invention. Every instrument belongs to a category. For every category, parameters are set up which 
indicate when a request for quote should be triggered. These categories include, for example, the deal amount 
exceeds a maximum allowed 18; the deal amount exceeds the available volume 20; the rate is suspended 22 due to 
^ sanity, spread, or time-out; the instrument is suspended 24; the counterparty is suspended 26; or the system is 
suspended 28. The default setting is all of the request for quote triggers switched on. For new categories added, 
the GUI displays the default settings. The trader 14 is able to switch off any or all of the request for quote 
triggers for a given category. Hence, for every warrants transaction, the WTS 6 only triggers the request for quote 
based on what the set-up is for that instrument category. 

[0038] In an embodiment of the present invention, the default setting is such that if any or all of the request 
for quote trigger situations arise, then the WTS 6 triggers a request for quote to the category traders. All of the 
reasons resulting in the request for quote are shown. If all of the request for quote (RFQ) trigger parameters are 
switched off except one, such as the instrument is suspended 24, then any warrants transaction is rejected in all 
the trigger circumstances, except when the instrument is suspended. If none of the RFQ triggers are switched on, then 
any of the trigger circumstances result in the WTS 6 transaction being rejected. All traders and system 
f5 administrators, with the privilege to maintain instruments, automatically have the access rights to maintain 
categories and RFQ trigger parameters. 

[0039] Fig. 3 shows a sample deal entry screen 30 for the request for quote aspect of an embodiment of the 
present invention. The customer 12 enters the instrument identification 32 and volume 34 and indicates whether the 
customer 12 wishes to buy or sell the warrant. The GUI validates the details and transmits the price quote request 
to the WTS 6. For every transaction, the WTS 6 checks whether any RFQ parameters are switched on or not. For the 
instrument specified by the customer 12 in the vwirrants transaction, the WTS 6 gets the RFQ parameters from the WRS 
8. The WTS 6 performs various checks, such as checking if the counterparty or system is suspended. If the relevant 
RFQ parameters, such as counterparty suspended 26 or system suspended 28 are set and the counterparty or system 
is suspended, then the WTS 6 acknowledges that a request for quote is required for the transaction. Othenwise, the 
transaction is rejected wn'th the appropriate message displayed on the screen of the customer GUI 2. If all is well, 

25 ttie WTS 6 passes tiie rate request to the WRS 8. 

[0040] In the request for quote aspect of an embodiment of the present invention, the WRS 8 performs various 
checks, such as instrument suspensions, rate suspensions due to sanity, spread or time-out. If any of these are true, 
and the relevant RFQ parameters, such as instrument suspended 24 or rate suspended 22, are set, then the WRS 8 is 
unable to quote a rate. The WRS 8 then acknowledges that a request for quote is needed and gives the reasons for it 
and passes these to the WTS 6. Otherwise, if the instrument or rate is suspended and the relevant RFQ parameters, 

30 such as instrument suspended 24 or rate suspended 22, are svwtched oft the transaction is rejected, and the GUI 
displays an appropriate message on the screen. In the existing CATS-OS system, the WRS 8 checks if the deal size 
exceeds available volume when the customer 12 executes a warrants transaction. However, in the request for quote 
aspect for an embodiment of the present invention, the WRS 8 does this check when the customer 12 requests a price 
quote. The WRS 8 checks if the deal amount exceeds the availatJe volume. If the deal amount is greater than the 
available volume, and the relevant RFQ parameter, namely exceeds available volume 20, is set, then the WRS 8 

35 acknowledges that a request for quote is needed, and this is sent to the WTS 6. Othenvise, if the WRS 8 is able to 
quote an executable rate automatically, the WRS 8 sends the quote to the WTS 6. , 

[0041] In the request for quote aspect of an embodiment of the present invention, the WTS 6 checks if the deal 
amount, determined by the buy or sell rate times the volume, exceeds the maximum transaction limit allowed. In the 
existing CATS-OS system, this check is done at deal execution time. In the request for quote aspect for an 

^ embodiment of the present invention, it is done when the customer 12 requests a price quote. If the amount exceeds 
the maximum limit, and the relevant request for quote parameter, namely exceeds maximum 18, is set, then the WTS 6 
acknowledges that a request for quote is required. Othenvise, the transaction is rejected. If all is well, and the 
WRS 8 quotes an executable rate, the executable rate is passed to the customer GUI 2 for the customer 12 to see. If 
the customer 12 executes the deal within a certain time period by pressing the "Buy" button 36 on the deal entry 
screen 30, the deal is executed. Alternatively, the customer 12 can press the "Cancel" button 38 on the deal entry 

45 screen 30, in which case the transaction is deleted. If a time-out occurs, then the customer 12 is either able to re- 
request a rate, by pressing tiie "Re-requesC button 40 on the deal entry screen 30, or cancel the deal. Re- 
requesting a deal results in the previous transaction being deleted and a new one being entered in the transactions 
database of the WTS 6. Othenmse, the transaction remains unexecuted. 

[0042] In the request for quote aspect of an embodiment of the present invention, if a request for quote is 
necessary, the WTS 6 informs the customer GUI 2. Including all the reasons for it The customer GUI 2 informs the 
50 customer 12 with a message, such as "Waiting for response from trader." The "Buy" button 36 is disabled, because the 
customer 12 cannot execute the deal until the dealer 14 accepts the indicated rate or provides a deal rate. The "Re- 
requesf button 40 and "Cancel" button 38 are enabled to allow the customer 12 to re-request a rate or delete the 
transaction. If the response of the trader 14 is not received wflthin a certain time period, the request for quote 
times out, and the customer GUI 2 informs the customer 12 with a message, such as "Sorry, no response from trader." 
P043] In the request for quote aspect of an embodiment of the present invention, a category trader 14 can 
respond to the request for quote by accepting the rate quoted by the WRS 4, by quoting a dealer's rate or by 
rejecting the transaction. The trader's request for quote response is sent by the WTS 6 to the customer GUI 2. If 
the category trader 14 rejects the request for quote, the customer GUI 2 validates that the details displayed on the 
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screen are the same as the request for quote. If so, the customer GUI 2 displays a message, such as "RFQ has been 
refused," and the "Re-request" button 40 and "Cancel" button 38 are enabled to allow the customer 12 to re-request a 
rate or delete the transaction. If the category trader 14 accepts the request for quote, the customer GUI 2 
validates that the trader's response to a request for quote relates to the transaction details displayed on the 
screen. If so, the customer GUI 2 then displays the dealer's rate and awaits the customer's response. The customer 
5 12 can reject the deal rate by pressing the "Cancel" button 38, in which case the transaction is deleted from the 
transaction database of the WIS 6. The customer 12 can accept the dealer's rate by pressing the "Buy" button 36, and 
the transaction is then executed. 

[0044] Fig. 4 shows a sample message box 44 for the request for quote aspect of an embodiment of the present 
invention. When a request for quote trigger occurs, the WIS 6 sends a notification message to the MA1 1 0. The MA1 10 
then sends a message to the on-line category traders alerting them of a request for quote. The category traders are 
able to see these system generated messages in the request for quote message box 44 or when they read their mail. 
However, if none of the category traders are logged on, then the MAI 10 sends the request for quote messages to all 
traders belonging to the default trader category. The default category traders are able to see the request for quote 
messages in the request for quote message box 44 or when they next read their mail. 

[0045] In the request for quote aspect of an embodiment of the present invention, every time a request for quote 
15 is triggered, If a trader in the same category is logged on, then the trader 14 is notified by a message in the status 
bar on the screen of the trader GUI 4 advising of an incoming message with time, text, and system name, such as 
"Incoming message: 10:47:52 *815725 request for quote RATES". If none of the category traders are logged on, then 
those default trader category members logged on receive the message. The trader 14 is able to select a message from 
the request for quote message box 44 and double click to provide a dealer's rate for the warrants transaction that 
is awaiting a rate quotation. The current transaction details then appear in the screen. Once the dealer 14 accepts 
20 or rejects the transaction, a mail message is added in the request for quote message box 44 notifying the category 
traders of the change in request for quote status. In addition, the trader GUI 4 displays the message in the status 
bar to alert the category traders of an incoming message with time, text, and system name, such as "Incoming 
message: 10:47:52 *815725 request for quote accepted RATES" or "Incoming message: 10:47:52 *815725 request for 
quote rejected RATES." If none of the category traders are logged on, then those default trader category members 
logged on receive the message. 

[0046] Fig. 5 shows a sample trade details screen 46 for the request for quote aspect of an embodiment of the 
present invention. When a request for quote is selected, the trader GUI 4 gets the transaction details from the WTS 
6. The transaction may not exist because the customer 12 may have decided not to wait for a trader's response and 
cancelled the deal. If this is the case, the trader GUI 4 displays a message, such as "Sorry, request for rates has 
been cancelled." Otherwise, the transaction details are displayed on the trade details screen 46 including the 

30 reason for the request for quote. The trader 14 can accept any rate quoted by the WRS 8, enter a dealer's rate, or 
reject the transaction. If the dealer 14 presses the "Accept" button 48 on the trade details screen 46, the request for 
quote status In the transaction database of the WTS 6 is updated accordingly. Similarly, the request for quote 
status is updated if the dealer 14 presses the "Reject' button 50 on the trade details screen 46. The result is 
transmitted from the trader GUI 14 to the WTS 6, and the result is sent on to the customer 12 at the customer GUI 2. 
The WTS 6 also broadcasts the updated request for quote status, via the MAI 10, to all of the on-line category 

35 traders. If the trader 14 rejects the request for quote, the customer GUI 2 displays a refusal message and enables 
the "Re-request" button 40 and "Cancel" button 38 on the deal entry screen 30. If the trader 14 accepts the request 
for quote, the customer GUI 2 displays the dealer's rate. The customer 12 can reject the deal rate by pressing the 
"Cancel" button 38 or accept the deal rate by pressing the "Buy" button 36, and the transaction is executed. 
[0047] Fig. 6 is a flow chart which illustrates an example of the process of the customer 12 requesting a rate 
in the request for quote aspect of an embodiment of the present invention. At S1, the customer 12 logs on the 

^ customer GUI 2 and enters an instrument identification 32, a volume 34, and indicates whether to buy or sell 36. At 
S2, the customer GUI 2 validates the details and sends the rate request to the WTS 6. At S3, the WTS 6 receives the 
rate request and checks if the counterparty or system is suspended. If not, the WTS 6 sends the rate request to the 
WRS 8. If the counterparty or system is suspended, the WTS 6 checks if the relevant RFQ parameters 26, 28 are set. 
If not, the WTS 6 sends a rejection message to the customer GUI 2. If the relevant RFQ parameters 26, 28 are set, 

^ the WTS 6 sends the rate request to the WRS 8. 

[0048] Referring further to Fig. 6, at S4, the WRS 8 receives the rate request and checks if the instrument or 
rate is suspended. If not, the WRS 8 checks if the deal size exceeds available volume. If the instrument or rate is 
suspended, the WRS 8 checks if the relevant RFQ parameters 24, 22 set. If not, the WRS 8 sends a rejection message 
to the WTS 6 for the customer GUI 2. If the relevant RFQ parameters 24, 22 are set, the WRS 8 checks if the deal 
size exceeds available volume. If the deal size does not exceed available volume, the WRS 8 sends an executable rate 

50 to the WTS 6. If the deal size exceeds available volume, the WRS 8 checks if the relevant RFQ parameter 20 is set 
If not, the WRS 8 sends a rejection message to the WTS 6 for the customer GUI 2. If the relevant RFQ parameter 20 is 
set, the WRS 8 sends an RFQ message to the WTS 6. At S5, the WTS 6 receives the executable rate from the WRS 8 
and checks if the deal amount exceeds the transaction limit If not, the WTS 6 sends the executable rate to the 
customer GUI 2. If the deal amount exceeds the transaction limit, the WTS 6 checks if the relevant RFQ parameter 18 
is set If not, the WTS 6 sends a rejection message to the customer GUI 2. If the relevant RFQ parameter 18 is set 

55 the WTS determines that a request for quote is required. 

[0049] Fig. 7 is a flow chart which illustrates an example of the request for quote notification process for the 
request for quote aspect of an embodiment of the present invention. At S6, the WTS 6 receives a request for quote 
message from the WRS 8 or determines that a request for quote Is required and sends a RFQ message to the customer 
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GUI 2 and a RFQ notification to the MAI 6. At S7, the customer GUI 2 receives the RFQ message from the WTS 6, 
disables the "Buy" button 36, enables the "Re-request" button 40 and "Cancer button 38, and sets a RFQ timer. At S8, 
the MAI 10 receives the RFQ notification from the WTS 6 and sends the RFQ notification to the trader GUI 4. At S9, 
the trader GUI 4 displays a RFQ message on the request for quote message screen 44. At S10, the trader 14 enters a 
selection of the request for quote message from the message screen 44. At S1 1 , the trader GUI 4 gets the transaction 

5 details from the WTS 6 and displays the details on the transaction details screen 46. 

[0050] Referring further to Fig. 7, at S12, the trader 14 enters an acceptance by pressing the "Accept' button 
48 or a rejection by pressing the "Reject" button 50 on the transaction details screen 46. At SI 3, the trader GUI 4 
sends the trader's acceptance or rejection to the WTS 6. At 814, the WTS 6 sends the trader's acceptance or 
rejection to the customer GUI 2, updates the request for quote status in the WTS transaction database, and 

,0 broadcasts the updated status via the MAI 10 to all on-line category traders. At S15. the customer GUI 2 receives 
the trader's acceptance or rejection. If a rejection, the customer GUI 2 displays a refusal message for the customer 
12. If an acceptance, the customer GUI 2 displays the trader's rate for the customer 12. At SI 6, the customer 12 
sees the display of the trader's rate and enters the customer's rejection by pressing the "Cancel" button 38 on the 
deal entry screen 30. Alternatively, if the customer 12 wants to accept the trader's rate and if the request for 
quote has not timed out, the customer 12 enters the customer's acceptance of the trader's rate by pressing the "Buy" 

15 button 36, and the transaction is executed. 

[0051] Another aspect for an embodiment of the present invention is a sales trader feature, which provides an 
automated system and method for wanrant trading that allows a special type of trader, referred to as a sales trader, 
to deal on behalf of a selected customer within the CATS-OS system. Fig. 8 is a schematic diagram which illustrates 
an overview example of key components and the flow of information between the key components in the sales trader 
aspect for an embodiment of the present invention. The sales trader aspect for an embodiment of the present 

20 invention makes use, for example, of one or more sales trader GUIs 102, 104, the warrants transaction server (WTS) 6, 
the warrants rate sen/er (WRS) 8, as well as a credit server (CRS) 106, a warrants hand-off server (WHO) 108 and a 
direct dealer interface (DDI) 110. In the sales wrader aspect, any number of sales traders 112, 114 perform this 
function without necessarily knowing the price of particular warrants and without setting their own prices. 
Typically, but not necessarily, one or more of these traders 1 12, 1 14 are located at terminals of the CATS-OS system, 
such as sales trader GUIs 102, 104, near the trading room itself. The sales traders 112, 114 receive calls from 
customers, such as customer 116, on the telephone 118 or other communication device in order to conduct trades for 
the customers. 

[0052] An advantage of the sales trader aspect for an embodiment of the present invention is that all the 
facilities of the CATS-OS system are available and fully met for the customers, including accurately set price, 
correctiy collected information, and other requirements for deals to proceed, such as credit lines in place. In 

30 addition the sales trader aspect provides the advantage of reduced error rates achieved by the CATS-OS system 
without the disadvantage of having to install all the CATS-OS system requirements for customers who do not wish 
installation but who wish to continue to deal over the telephone 118. The sales trader aspect thus provides full 
warrant trading capabilities without the expense of highly paid professional traders or inter-bank traders. The 
sales trader aspect also includes specialized features relating to trading by phone 118 and customer account access. 
In the sales trader aspect, the sales traders 112, 114 have privileged access to user accounts. In this embodiment, 

35 the sales traders 112, 114 do not have access to all capabilities that normal users of the CATS-OS system have, 
but the system does provide the sales traders 112, 114 with the capability to select the customers, such as customer 
1 1 6, on whose behalf they are acting and to perform certain necessary functions to "complete warrant trading. 
[0053] In the sales trader aspect of an embodiment of the present invention, when the sales traders 112, 1 14 log 
in, input of name and password information allows the sales traders 112, 114 to deal on behalf of a number of users 
in a secure manner. The seies trader aspect permits a user to trade in the CATS-OS system on behalf of its customers 

^ and makes use, for example, of the GUI and the servers in the existing CATS-OS system to increase the number of 
vrarrants transactions done through the CATS-OS system. The sales trader aspect enables tills by including warrants 
transactions done with customers, such as customer 116, over the telephone 118. This new type of user is able to 
enter transactions in the CATS-OS system on behalf of customers. 

[0054] As the existing CATS-OS system provides an automatic deal hand-off to the DDI 110, a benefit of the sales 
^ trader aspect for an embodiment of the present invention includes, for example, a significant reduction in the wrong 
rates being quoted or entered accidentally into the system by traders. Currentiy, many telephone trades are 
■ mismatched and have to be adjusted by a middle office. Another benefit of the sales trader aspect for an embodiment 
of the present invention is to avoid manual work and hand-written tickets, thus saving time for the trader. An 
additional benefit of the sales trader aspect is that the CATS-OS system GUI software application need not be 
installed at the customer's site, because the sales traders, such as sales traders 112, 114, are able to enter and 
50 view transactions on behalf of customers. 

[0055] Fig. 9 is a schematic diagram which illustrates an example overview of databases for the sales trader 
aspect of an embodiment of the present invention. The sales trader aspect includes, for example, an "Institution" 
table 118, a "Branch" table 120, a "User table 122, and a "Customer" table 124. In the sales trader aspect, the non- 
CATS-OS system bank counterparty details are manually entered into the "Branch" table 120 of the CATS-OS system. 
In addition, the trading relationships and credit limits are manually maintained from relationship and credit limit 
^ maintenance screens. The existing customers' GUI trading mechanism is not changed. The DDI 110 stores additional 
fields, such as customer identification and retail customer's setUements instructions, in a DDI interface table and 
Exchange Feed table of the existing CATS-OS system. A customer Sst is uploaded from a text file into the CATS-OS 
system database. Thereafter, the "Customer" table 124 of the CATS-OS system Is manually maintained by a system 
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administrator. The sales traders, such as sales traders 112, 114, do not have the privilege to negotiate prices or 
override maximum transaction amount being deleted. This privilege is available to traders who are able to respond to 
pending transactions that await request for quotes. 

[0056] The sales trader aspect for an embodiment of the present invention utilizes a number of servers. The WTS 
6 coordinates the activities of the CATS-OS system. The WTS 6 contains a database which stores user profiles, 
* transactions and relationships. The WRS 8 receives input from price feeds, such as Reuters price feeds, and updates 
an in-memory table wflth the latest rates. The WRS 8 stores and updates volumes and warrants instrument details. The 
CRS 1 06 maintains the credit for each branch. The credit is drawn down each time a transaction is executed. The WHO 
108 receives the completed transactions and hands them off to the deal capture and position-keeping system or DDI 
110. 

[0057] In the sales trader aspect for an embodiment of the present invention, the customer 116 is an individual 
who has an account at a host retail bank branch, such as a global consumer bank. Alternatively, the customer 116 is 
a fund manager or broker of a corporate entity or bank that uses the CATS-OS system to execute warrants transactions 
against a branch of the host bank. The customer 1 16 is set up in the "User" table 122 vwth the user type "Customer" 
and a user ID as a unique identifier. The traders, such as trader 112, are the corporate warrants dealers at a 
branch of the host bank. A trader, such as trader 112, is responsible for making the prices, setting trading limits 

IS and covering positions resuRIng from transactions in local currency. The trader, such as trader 112, is set up in 
the "User" table 122 with user type 'Trader" with a unique identifier or user ID. A counterpart/ is the corporate 
entity, bank, or financial institution that uses the CATS-OS system to execute warrants transactions against a branch of 
the host bank. The counterparty is set up in the "Branch" table 120 with a unique identifier or branch ID. 
[0058] In the sales trader aspect for an embodiment of the present invention, a sales trader, such as trader 112, 
is a new type of user of the CATS-OS system. For example, the sales trader 112 is either a host bank employee or a 

^ host bank broker who deals over the telephone 118, for example, v^h a host bank counterparty. The sales trader 112 
is able to enter and view transactions on behalf of a customer 116 of the CATS-OS system. The customer 1 16 is also 
able to log into the CATS-OS system itself. The customer 1 16 can then be manually added as a CATS-OS system user 
from a user profile maintain screen. An organization Is classed as an "Institution" in the CATS-OS system. An 
institution is stored in the "Institution" table 118 with a unique identifier or institution ID. For example, a 
company called "The Acme Company" is set up with an institution ID of "ACMEINST." A branch Is an instance of a bank 
branch or a corporate branch held in the "Branch" table 120 with a branch ID. The Acme Company with branches In 
London, Frankfurt and Tokyo has branches, for example, "LONACME", "FFTACME", and "TOKACME" set up in the 
CATS-OS system. 

[0059] In the sales trader aspect for an embodiment of the present invention, a relationship describes the 
trading relationship which the trading branch has with all other host bank counterparties. As long as a trading 

30 relationship exists between the two relevant branches, a sales trader of the trading branch, such as sales trader 
112, can trade on behalf of any of the counterparties or the counterparty's retail customers, if any. Hence, a sales 
trader Is not restricted to trade on behalf of a subset of counterparty customers. Fig. 10 is a schematic diagram 
which amplifies and provides further detail regarding the sample database oven/lew shown in Fig. 9 for the sales 
trader aspect of an embodiment of the present invention. In accordance with the existing CATS-OS system trading 
mechanism, all warrants transactions are done bank to bank. For example, a sales trader, such as sales trader 112, 

35 of the host bank in Japan trading on behalf of a retail customer or a global consumer bank, such as customer 116, 
results in the deal being done, for example, between "CITIJPY" and "CITIGCB." 

[0060] In the sales trader aspect for an embodiment of the present invention, a sales trader transaction has its • 
own time-out period for which the warrant's price is valid. This time-out period is maintained in the "Branch" table 
120 against the branch of the sales trader 112. The time-out period is longer, for example, than the normal price 

^ time-out period. This is because there is some time delay between the buy/sell price being quoted to the customer 
116 over the phone 118, and the customer 116 stating the transaction volume and whether the customer 116 wishes to 
buy or sell. It is possible that the price of the warrant is updated in the meantime. The transaction is still 
executed vnth the buy/sell price quoted, as long as the sales trader time-out period does not expire. 
[0061] Figs. 11, 12, 13, 14, and 15 illustrate a sample deal entry screen 130, a sample transaction screen 132, 
branch maintenance screen 134, a sample customer maintenance screen 136, and a sample trade details screen 138, 

45 respectively, for the sales trader aspect of an embodiment of the present invention. The GUI 102 and the WTS 6 
assure that the sales trader transaction is executed vwthin the new time-out period. If not, the GUI 102 displays a 
time-out message and disables the "Buy" button 140 and "Sell" button 142 from the deal entry screen 130. The sales 
trader 112 can then re-request a price quotation by pressing a the "Re-requesf button 144 or cancel the transaction 
by pressing the "CanceT" button 146 on the deal entry screen 130. When the sales trader 112 enters the warrants 
transaction in the CATS-OS system, the sales trader 1 12 enters it as a broker of the trading branch. In other words, 

50 if the customer 116 says "I wish to buy X warrants", the sales trader 112 enters "sell" by pressing the "Seir 
button 142 on the deal entry screen 130 Similarty, if the customer 116 says "I wish to sell X warrants", the sales 
trader 1 12 enters "buy" by pressing the "Buy" button 140 on the deal entry screen 130. 

[0062] In the sales trader aspect of an embodiment of the present invention, when the customer 116 telephones 
the sales trader 112 and requests to make warrants transaction, the sales trader 112 at the sales trader GUI 102 
logs into the CATS-OS system. The transaction screen 132 is displayed automatically to the user 112. The 
°^ transaction screen 132 is more detailed than the one normally shown to the CATS-OS system customers. The sales 
trader 112 enters the warrants stock exchange number (SE No.) 148. The sales trader 112 then enters a kV number 
150 or depot number 152. if known. The kV number is given to banks or financial institutions that trade on the 
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German stock exchange. Those with a kV number settle their account through the German clearing system. Those with 
a depot number are non-German banks or financial institutions that settle directly. The GUI 102 defaults to entry of 
kV number 150. The kV number 150 or depot number 152 identifies domestic or non-domestic bank approved 
counterparties. 

[0063] Alternatively, in the sales trader aspect for an embodiment of the present invention, the sales trader 
112 can enter the counterparty branch name 154. The sales trader 112 can request a list of branch names starting 
with X characters (maximum of eight characters). If the sales trader 112 enters a search string and presses a "Find" 
button 156 on the branch maintenance screen 134, the GUI 102 ensures that some search criteria has been entered. 
The WTS 6 checks the "Branch" table 120 to see if the first few characters of the branch names match the search 
criteria. If matching branch names are found, the WTS 6 returns the total number of matching branch ID's and names. 
If there are more than 100 matching branch ID's, the WTS 6 does not return any of the branch details and a message, 
such as "XXX matching branch names were found, please re-enter search criteria" is displayed. If none are found, a 
message is displayed, such as "None found; please re-enter search criteria." 

[0064] In the sales trader aspect for an embodiment of the present invention, for trading on behalf of retail 
bank customers, the sales trader 112 enters the customer ID 158, if known. Othenvise, the sales trader 112 can 
request customer names starting with x characters (maximum of eight characters). If the sales trader 112 enters a 
search string and presses the "Find" button 160 on the customer maintenance screen 136, the GU1 102 ensures that 
some search criteria has been entered. The WTS 6 checks the "Customer" table 124 to see if the first few 
characters of the customer names match the search criteria. If matching customer names are found, the WTS 6 returns 
the total number of matching customer ID's and names. If there are more than 100 matching customer ID's, the WTS 6 
does not return any of the customer details and a message, such as "XXX matching customer names were found, 
please re-enter search criteria" is displayed. If .none are found, a message Is displayed, such as "None found; 
please re-enter search criteria." 

[0065] In the sales trader aspect of an embodiment of the present invention, the sales trader 112 does not know 
the volume the customer 116 wishes to buy or sell. Once the CATS-OS system quotes a buy and sell price, the 
customer 116 decides the volume and whether to buy/sell. The sales trader 112 can request a price quotation by 
pressing a "Get Price" button 162 on the transaction screen 132. The GU1 102 ensures that a kV or a depot number has 
been entered. Othenvise, a message is displayed, such as "Please enter a kV/depot no or counterparty name," and the 
sales trader 112 is prompted for re-input. The WTS 6 then validates the kV or depot number entered. If the 
counterparty specified does not exist, then the syretem administrator must manually enter this branch, its trading 
relationship with a trading branch, and credit limits in the CATS-OS system, and a message will be displayed, such 
as "Invalid branch". If a customer ID is entered, the WTS 6 validates that it exists in the "Customer" table 124. If 
not, a message will be displayed, such as "Invalid customer". The system administrator must manually enter the 
customer details in the customer maintenance screen 136. On successful validation, the WRS 8 generates a two-way 
price quote, which is both the buy and sell price for sales trader transactions. Before executing the transaction, 
the sales trader 112 must enter the volume. If not, the GUI 102 prompts the sales trader 112 for re-entry of the 
volume field. Once the customer 116 accepts the rate quoted within the new time-out period, the sales trader 112 
executes the transaction by pressing either the "Buy" button 140 or the "Seir button 142 on the deal entry screen 130. 
[0066] In the sales trader aspect for an embodiment of the present invention, if the CATS-OS system is unable to 
quote a price and the relevant request for quote (RFQ) parameters are switched on, the WTS 6 and/or the WRS 8 
triggers a RFQ to the relevant category traders that are logged in. The GUI displays a message indicating the 
reason for a RFQ. The sales trader 112 then waits for a trader to respond to the RFQ and quote a price. Otherwise, 
the sales trader 112 can re-request a price or cancel the transaction. The WTS 6 and the WRS 8 check to determine 
whether the deal amount exceeds the maximum transaction limit and whether the deal amount exceeds the available 
volume. If so, and the relevant RFQ parameters are switched on, a RFQ is triggered. The GUI displays a message 
indicating the reason for the RFQ. The sales trader 112 then waits for a trader to respond to the RFQ and quote a 
price. Othenvise, the sales trader 112 can re-request a price or cancel the transaction. When the sales trader 112 
executes or cancels a transaction, the sales trader's branch credit limit Is updated accordingly. 
[0067] In the sales trader aspect of an embodiment of the present invention, the sales trader 112 sees the 
customer maintenance screen 136. In a customer reference field, the sales trader 112 enters the counterparty's 
employee name. The customer reference field can be used to view transactions and reports. On successful execution, 
the WTS 6 updates the volume on the transaction table. The transaction is then automatically handed to the DDI 1 10. 
For example, for every Japanese sales trader warrants transactions handed off to the DDI 110, the WHO 108 sends 
additional fields to the DDI 110. These are the customer ID 164, such as the retail customer bank account number, 
and the retail customer name 166. The customer ID 164 and name 166 fields are valid for transactions with retail 
bank customers; otherwise, it is blank. The retail customer's settlements instructions, l.e., customer ID 164 and 
name 166, are deemed a mandatory field, for example, for Japanese back office settlements operations. The WTS 6 
hands off the customer ID and name for every transaction to the WHO 108. The WHO 108 only hands off, for example, 
the addit'onal two fields for Japanese transactions. 

[0068] In the sales trader aspect of an embodiment of the present invention, for those banks or financial 
institutions that do not settle, for example, through a German clearing house, the warrants transaction amounts are 
settled directly between the trading bank or financial institution and the counterparty bank or financial 
institution. This is done using a depot number, such as the branch plus a base plus an account number. German banks 
or financial institutions that go through the clearing house settle, for example, by using the German stock exchange 
number or kV number in the DD1 110. For vrarrants transactions with retail bank customers, their accounts are settled, 
for example, by a back office settlements system. 
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[0069] In an embodiment of the present invention, for sales trader transactions, deal tickets show a sales 
trader user ID and counterparty customer ID. An "Entered by" field in the deal ticket is the sales trader's user ID. 
The WTS 6 generates deal tickets with additional fields, such as the customer's ID and customer's name. These are 
only valid for sales trader transactions executed on behalf of retail bank customers. Otheiwise they are blank. For 
sales trader transactions, transaction reports show the sales trader's user ID and counterparty's customer ID. The 
5 "Entered b/' field 168 in the transaction report is the sales trader's user ID. The WTS 6 generates transaction 
reports with additional fields, such as the customer's Id and retail customer's settlements instructions. These are 
only valid for sales trader transactions executed on behalf of retail bank customers. Othenvise they are blank. 
[0070] In the sales trader aspect of an embodiment of the present invention, for sales trader transactions, two 
way price quotation is necessary. When the sales trader 112 enters a transaction and the CATS-OS system is unable to 
quote prices, an RFQ is triggered if the RFQ parameters are switched on. In other words, category traders are 
expected to respond to an RFQ and quote a two way price. An RFQ may be triggered If the rate, instrument, 
counterparty, or system Is suspended, or if the deal amount is greater than the maximum transaction limit or the 
deal amount is greater than available volume. The volume and buy/sell field may be blank for sales trader 
transactions. The GUI and the WTS 6 ensure that the trader responds within the new time-out period for sales trader 
transactions. 

15 [0071] Rg. 16 is a flow chart which illustrates a sample sales trader transaction for the sales trader aspect 
of an embodiment of the present invention. At SI 01, the customer 116 at a telephone 118 contacts the sales trader 
112 and requests a warrants transaction. At SI 02, the sales trader 112 at the sales trader GUI 102 logs in and 
inputs the sales trader's name and password information, enters the customer's warrants transaction information, and 
presses the "Get Price" button 162 for a price quote request. At S103, the sales trader GUI 104 sends the price 
quote request to the WTS 6. At S104, the WTS 6 validates the entered information, checks RFQ parameters, and if 

20 applicable, triggers the RFQ process; or if not applicable, sends the price quote request to the WRS 8. 

[0072] Refemng further to Fig. 16, at 8105, the WRS 8 checks RFQ parameters, and if applicable, triggers the 
RFQ process; or If not, generates a two-way buy-sell price quote and sends it to the WTS 6. At SI 06, the WTS 6 sends 
the price quote to the sales trader GUI 112. At S112, the sales trader GUI 102 displays the price quote for the 
sales trader. At S114, the sales trader 112 communicates the price quote to the customer 116. At S107, the customer 

,e 116 responds to the sales trader 112 with the customer's decision to reject or accept the price quote, and if 
accepted by the customer 116, the customer's desired volume. At S108, the sales trader 112 enters the customer's 
rejection by pressing the "Cancel" button 146, or if accepted by the customer 116, enters the customer's desired 
volume and executes the transaction by pressing tiie "Buy button 140 or "Sell" button 142. 

[0073] An additional aspect for an embodiment of the present invention is a multi-bank feature, which provides a 
system and method for automated warrant trading that allows a plurality of banks to deliver their prices using the 
30 CATS-OS system. The multi-bank aspect enables the single bank CATS-OS system to perform in a multi-bank mode by 
establishing links to one or more additional banks. Trading data is collected from the other banks, and once a deal 
is done, the deal is returned to a particular bank so that it can then manage the position which it has and perform 
its own assessment and the like. The multi-bank aspect for an embodiment of the present invention converts the 
single bank automated warrant trading CATS-OS system to a multi-bank automated warrant trading system and 
method. 

^5 [0074] Fig. 17 is a schematic diagram which Illustrates an example overview example of key components and the 
flow of information between the key components for the multi-bank aspect of an embodiment of the present invention. 
The multi-bank aspect avoids the potential problem of being overiy embedded. For example, if a bank offers competing 
prices, there are potential regulatory problems, such as a claim that the bank is conducting a stock exchange. In 
other words, when a bank allows many different competing prices on one system, the system may be claimed to be in 

^ effect a stock exchange. The multi-bank aspect for an embodiment of the present invention avoids the claim that it 
is a stock exchange, because the system does not have direct price competition between different banks using the 
multi-bank aspect of the system. 

[0075] The single bank CATS-OS system is an end tier client-server system, an advantage of which is that the 
different functions are very well partitioned. The functions of the single bank system include the rate server or 
WRS, which receives and fulfills rate requests from the transaction server or WTS, and a hand-off server or WHO, 
45 which hands off complete transactions to a direct dealer interface or DDI. The WRS receives rights from the bank and 
manages and presents them to the rest of the system as required, and the WHO receives bills from the system and 
hands them off to the bank and provides a reconciliation process. The single bank CATS-OS system also includes the 
WTS and layers of security and messaging which tie the whole system together. 

[0076] In the multi-bank aspect of an embodiment of the present invention, In addition to a first bank's WTS 6, 
for example, one or more additional transaction servers, such as a second bank's WTS 202, are employed, which are 
completely independent from the first bank's WTS 6 and completely independent from one another. Each additional 
transaction server, such as the second bank's WTS 202, deals exclusively with an additional bank, such as the second 
bank, in the multi-bank aspect for an embodiment of the present invention. Likewise, one or more additional rate 
servers, such as the second bank's WRS 204, and one or more additional hand-off servers, such as the second bank's 
WHO 206, are provided, which enables segregation between the multiple banks. A customer 208 uses a graphical user 
interface (GUI) 210 coupled via a network 212 to shared communications and messaging layers 214 to the separate 
automated warrant trading systems of a plurality of banks, such as trading systems 21 6 and 21 8. 
[0077] In the multi-bank aspect for an embodiment of the present invention, the separate automated warrant 
trading systems 216 and 218 of each bank includes, for example, the separate transaction servers WTS 6 and WTS 
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212 coupled to the shared communications and messaging layers 214, and the separate rate senders WRS 8 and WRS 
204 and hand-off servers WHO 7 and WHO 216 coupled to the respective transaction servers WTS 6 and WTS 202. 
Further, each bank's separate trading system 216, 218 includes a firewall 220, 222, established between the 
respective banks' rate servers WRS 8 and WRS 204 and hand-off sen/ers WHO 7 and WHO 216, and the respective 
banks' data centers 224, 226. Thus, one bank on the multi-bank system is not allowed to see how another bank on the 
5 system deals with the particular customer 208. While the multi-bank aspect utilizes shared communications and 
messaging layers 214, it runs independently on each end user's system. The multi-bank aspect is transparent to each 
of the banks using the system. As far as a particular bank using the multi-bank system is concerned, it is the only 
bank on the system. 

[0078] Currently, the CATS-OS system runs very successfully as an automated electronic trading tool for a bank's 
customers, for example, in Germany. These customers are primarily brokers, so the bank is often not aware of the 
identity of the end customer. The multi-bank aspect for an embodiment of the present invention allows other banks to 
add their prices to the CATS-OS system, so these brokers can buy and sell their warrants as well. This has an 
advantage for the brokers in that they only have to deal v«th one system to in order to meet their customers' needs. 
The multi-bank aspect for an embodiment of the present invention enables an entity, such as a wholly owned 
subsidiary of a bank, to provide a system which deals with hundreds of other banks, corporations and/or fund 
15 managers by demonstrating the ability of the subsidiary to maintain a separation between the bank and itself, as 
well as all other parties. Such an entity can be responsible for both the software and hardware for the CATS-OS 
system and can run the system in its own data center 228 and provide a clearly defined hand-off between its parent 
bank and itself. 

[0079] The multi-bank aspect of an embodiment of the present invention enables the CATS-OS system user 208 to 
easily buy and sell warrants from a number of banks and market makers. If the user 208 accesses the system through 
20 dial-up, the user 208 does not to have to disconnect and re-dial to deal v\nth another bank. The user 208 does not to 
have to log in separately, for example, to each of the systems 216, 218. Further, the systems 216, 218 are not so 
integrated as to raise fears that a stock exchange Is created. Additionally, segregation between price makers is 
maintained. The multi-bank aspect for an embodiment of the present invention provides a fast, secure and reliable 
method of extracting rates from the price maker and returning to the bank any resultant deals in a timely and 
reliable fashion. 

[0080] In the multi-bank aspect for an embodiment of the present invention, an extra level of functionality can 
be added to the current user front-end GUI to allow the extra banks to be visible. Alternatively, for a relatively 
small number of banks, the GUI can be run a number of times, once for each available bank. In the alternative 
approach, the user 208 simply clicks from one system to the other as needed. A mechanism is also provide to enable 
this w/ith the keyboard only- This can be accomplished, for example, with changes to the GUI and a higher 

30 specification machine to run more than one program at once. In the multi-bank aspect for an embodiment of the 
present invention, users of both the first bank's system 216 and the second bank's system 218 only have access to 
the systems via their GUIs, and segregation of all functions are maintained. An entity such as a subsidiary of the 
first bank can act in the mode of system administrator. A decision can be made as to which customers are enabled for 
which banks. The system can still be used as a single bank system as needed. Predetermined business arrangements 
are entered, for example, between the first bank, its subsidiary and the other banks, such as the second bank. 

35 [0081] Fig. 18 is a flow chart which illustrates an example of the process of a customer transaction in the 
multi-bank aspect for an embodiment of the present invention. AtS201, the customer 208 at the customer GUI 210 logs 
on and enters the customer's price quote request. At S202, the customer GUI 210 sends the price quote request via 
shared communication and messaging layers 214 simultaneously to the WTS 6 and the WTS 202 of the separately 
maintained and segregated trading systems 216 and 218. At S203, the WTS 6 and the WTS 202 each sends the price 
quote request to the corresponding WRS 8 and WRS 204 of its own ti-ading system 216 or 218. At S204, each of the 

^ WRS 8 and WRS 204 independentiy generates an executable rate and sends the rate to the corresponding WTS 6 and 
WTS 202 of its own trading system 218 or 218. At 8205, each of the WTS 6 and the WTS 202 sends its own trading 
system's rate quote via the shared communication and messaging layers 214 to the customer GUI 210. 
[0082] Referring further to Fig. 18, at S206, the customer GUI 210 receives and displays each of the rate quotes, 
such that the rate quote and the identity of the financial institution's trading system 216 or 218 which furnished 

4g the rate quote are known only to the customer 208 and the financial institution which furnished the rate quote. At 
S207, the customer 208 at the customer GUI 210 enters the customer's selection of one of the rate quote furnished by 
one of the trading systems 216 or 218. At S208, the customer GUI 210 sends the customer's acceptance via the shred 
communication and messaging layers 214 to the WTS 6 or the WTS 202 of the trading system 216 or 218 which 
furnished the selected rate quote, such tiiat the selection is known only to the customer 208 and the financial 
institution whose trading system 216 or 218 furnished the selected rate quote. At S209, the WTS 6 or the WTS 202 of 

SO the trading system 216 or 218 which furnished the selected rate quote receives the customer's acceptance and sends 
the acceptance to corresponding WHO 7 or 206 of the trading system 216 or 218 which furnished the selected rate 
quote for processing. 

[0083] Although the invention has been described with reference to these preferred embodiments, other 
embodiments can achieve the same results. Variations and modifications of the present invention will be apparent to 
one skilled In the art, and the above disclosure is intended to cover. all such modifications and equivalents. 
^ Accordingly, the invention is only limited by the following claims. 



Claims 
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1. A method for data management of a financial transaction, comprising: 



receiving a request for a user (12, 116, 208) for a proposed financial transaction; 

generating a rate quote consisting of one of an executable rate quote and a category trader's rate quote for 
the proposed financial transaction, wherein the executable rate quote is generated if a first predefined 
condition is identified, and the category trader's rate quote Is generated if a second predefined condition 
is identified; 

automatically prompting the user (12, 116, 208) for a selection of the generated rate quote for the proposed 
financial transaction; 

automatically holding the generated rate quote for a predetermined period of time for the user (12, 116, 208); 

receiving a request for execution of the proposed transaction for the user (12, 116, 208) in accordance with 
tiie selection by the user (12, 116, 208) of the generated rate quote; and 

automatically executing the proposed transaction for the user (12, 116, 208) In accordance with the 
generated rate quote upon receipt of the request for execution within the predetermined period of time. 



2. The method of claim 1, wherein receiving the request for the proposed financial to'ansaction further comprises 
receiving the request at a terminal (2, 210; 4. 102, 104). 

3. The meUiod of claim 2, wherein receiving the request at the terminal (2, 210) further comprises entering the 
request at the terminal (2, 210) by the user (12, 116, 208). 

4 The method of claim 2, wherein receiving the request at the terminal (4, 102, 104) further comprises entering 
the request at the terminal (4, 102, 104) for the user (12, 116, 208) by a sales trader (1 12, 114), 

5. The method of claim 4. wherein entering the request at the terminal (4, 102, 104) by the sales trader (112, 114) 
further comprises receiving the request by the sales trader (112, 114)from the user(116, 208). 

6. The method of claim 2, wherein receiving the request at the terminal (2, 210; 4, 102, 104) further comprises 
receiving the request by a transaction server (6, 202) coupled to the terminal (2, 21 0; 4, 1 02, 1 04). 

7. The method of claim 6, wherein receiving the request at the terminal (2, 210; 4, 102, 104) further comprises 
receiving the request by a rate server (8, 204) coupled to the transaction sen/er (6. 202). 

8. The method of claim 2, wherein receiving the request at the terminal (2, 210; 4, 102, 104) further comprises 
receiving the request by a plurality of transaction sewers (6, 202) coupled to the terminal (2, 210; 4, 102, 104). 

9. The method of claim 8, wherein receiving the request at the terminal (2, 210; 4, 102, 104) further comprises 
receiving the request by the transaction servers (6, 202) of each of a plurality of independentiy maintained and 
segregated trading systems (216, 218) coupled to the terminal (2, 210; 4, 102, 104). 

10. The method of claim 9, wherein receiving the request at the terminal (2, 210; 4, 102, 104) further comprises 
receiving the request by a corresponding rate server (8, 204) coupled to the transaction sen/er (6, 202) of each 
of the trading systems (216, 218). 

11. The method of claim 1, wherein generating the rate quote further comprises automatically identifying the first 
predefined condition for generating the executable rate quote for the proposed transaction by at least one of a 
transaction server (6, 202) and a rate server (8, 204). 

12. The method of claim 11, wherein automatically identifying the first predefined condition for generating the 
executable rate quote further comprises automatically generating the executable rate quote by the rate server (8, 
204). 

13. The method of claim 12, wherein automatically generating the executable rate quote by the rate server (8, 204) 
further comprises automatically generating the executable rate quote by the rate sen/er (8, 204) coupled to the 
transaction server (6, 202). 

14. The method of claim 12, wherein automatically generating the executable rate quote by the rate server (8, 204) 
further comprises automatically generating the executable rate quote by the rate server (8, 204) of at least one 
of a plurality of Independentiy maintained and segregated trading systems (216, 218). 
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15. The method of claim 14, wherein automatically generating the executable rate quote by the rate server (8. 204) 
of at least one of the plurality of trading systems (216, 218) further comprises automatically generating the 
executable rate quote by the rate server (8, 204) coupled to a corresponding transaction seiver (6, 202) of the 
at least one independentty maintained and segregated trading system (216. 218). 

16. The method of claim 1, wherein generating the rate quote further comprises automatically identifying the second 
predefined condition for generating the category trader's rate quote. 

17. The method of claim 16, wherein automatically identifying the second predefined condition for generating the 
category trader's rate quote further comprises automatically identifying a predefined cause for rejecting the 
request for the proposed financial transaction. 

18. The method of claim 17, wherein automatically identifying the predefined cause for rejecting the request for 
the proposed financial transaction further comprises automatically identifying the predefined cause for rejecting 
the proposed financial transaction by at least one of a transaction server (6, 202) and a rate server (8, 204). 

19. The method of claim 18, wherein automatically identifying the predefined cause for rejecting the proposed 
financial transaction further comprises automatically identifying at least one cause for rejecting the proposed 
financial transaction selected from a group of causes for rejecting the proposed financial transaction consisting 
of a proposed transaction counterparty suspension, a proposed transaction system suspension, a proposed 
ti-ansaction instrument suspension, a proposed transaction rate suspension, a proposed transaction volume 
exceeding an available volume, and a proposed transaction amount exceeding a predefined limit. 

20. The method of claim 17, wherein automatically generating the request for the category trader's rate quote 
further comprises automatically confimning a predetermined setting of a request for quote parameter coresponding 
to the at least one identified predefined cause for rejection of the proposed financial transaction. 

21. The method of claim 20, wherein automatically confirming the request for quote parameter setting further 
comprises automatically confirming the request for quote parameter setting by at least one of the transaction 
sen/er (6, 202) and the rate sender (8, 204). 

22. The method of claim 16, wherein automatically identifying the second predefined condition for generating the 
category trader's rate quote further comprises automatically prompting entry of the category trader's rate quote 
by at least one of a plurality of category traders. 

23. The method of claim 22, wherein automatically prompting the entry of the category trader's rate quote further 
comprises receiving an Input of the category trader's rate quote by at least one of the plurality of category traders. 

24. The method of claim 1, wherein automatically prompting the user (12, 116, 208) for selection of the generated 
rate quote further comprises automatically displaying the generated rate quote for the user (12, 116, 208). 

25. The method of claim 24, wherein automatically displaying the generated rate quote further comprises 
automatically displaying the generated rate quote forthe user (12, 116, 208) at a terminal (2, 210; 4, 102, 104). 

26. The method of claim 25, wherein automatically displaying the generated rate quote further comprises 
automatically displaying the generated rate quote at a user terminal (2, 21 0) for the user (12, 1 16, 208). 

27. The method of claim 25, wherein automatically displaying the generated rate quote automatically displaying the 
generated rate quote at a sales trader terminal (4, 102, 104) for the user (12, 116. 208). 

28. The method of claim 1, wherein automatically holding the generated rate quote for the predetermined period of 
time for the user (12, 116, 208) further comprises automatically setting a counter for the predetermined period 
of time. 

29. The method of claim 1, wherein receivirig the request for execution of the proposed transaction further 
comprises receiving the request for execution at a terminal (2, 210; 4, 102, 104). 

30. The method of claim 29, wherein receiving the request for execution at the terminal (2, 210; 4, 102, 104) 
further comprises entering the request at a user terminal (2, 210) by the user (12, 116, 208). 

31. The method of claim 30, wrtierein receiving the request for execution at the terminal (2. 210; 4, 102, 104) 
further comprises entering the request at a sales trader terminal (4, 102, 104) by a sales trader (14, 112, 114) 
forthe user(12, 116, 208). 

32. The method of claim 31, wherein entering the request for execution at the sales trader terminal (4, 102, 104) 
by the sales trader (14, 112, 114) further comprises receiving the request by the sales ti-ader (14, 112, 114) 
from the user (12, 116, 208). 
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33. The method of claim 29, wherein receiving the request for execution at the terminal (2, 210; 4, 102, 104) 
further comprises receiving the request for execution by a transaction server (6. 202) coupled to the terminal (2; 
210; 4. 102, 104). 

5 34. The method of claim 33. wherein receiving the request for execution at the terminal (2, 210; 4. 102, 104) 
further comprises receiving the request for execution by the transaction sen/er (6, 202) of one of a plurality of 
independently maintained and segregated trading systems (216. 218) coupled to the terminal (2, 210; 4, 102, 104). 

35. The method of claim 1, wherein automatically executing the proposed transaction for the user (12. 116. 208) 
further comprises automatically handing off the request for execution to a hand-off server (7, 1 08, 206). 

36. The method of claim 35, wherein automatically handing off the request for execution further comprises 
automatically handing off the request for execution by a transaction server (6, 202). 

37. The method of claim 35, wherein automatically handing off the request for execution further comprises 
^5 automatically handing off the request for execution by a transaction server (6. 202) of one of a plurality of 

independentiy maintained and segregated trading systems (216. 218). 

38. A system for data management of a financial transaction, comprising: 

means for receiving a request for a user (12, 1 16. 208) for a proposed financial transaction; 

20 

means coupled to the transaction request receiving means for generating a rate quote consisting of one of an 
executable rate quote and a category trader's rate quote for the proposed financial transaction, wherein the 
executable rate quote is generated if a first predefined condition is identified, and tiie category trader's 
rate quote is generated if a second predefined condition is identified; 

25 means coupled to the rate generating means for automatically prompting the user (12. 116, 208) for a 

selection of the generated rate quote for the proposed financial transaction; 

means associated with the prompting means for automatically holding the generated rate quote for a 
predetermined period of time for the user (12. 1 16. 208); 

means associated with the prompting means for receiving a request for execution of the proposed transaction 
for the user (12. 116, 208) in accordance witii the selection by the user (12, 116, 208) of the generated 
rate quote; and 

means coupled to the execution request receiving means for automatically executing the proposed transaction 
35 for the user (12, 116. 208) In accordance with the generated rate quote upon receipt of the request for 

execution vwthin the predefined period of time. 



39. The system of claim 38, wherein the means for receiving the request for the proposed financial transaction 
further comprises a terminal (2, 210; 4, 102, 104) consisting of one of a user's terminal (2, 210) and a sales 

40 trader's terminal (4, 1 02, 1 04). 

40. The system of claim 39, wherein the means for receiving the request for the proposed financial transaction 
further comprises at least one transaction server (6, 202) coupled to the terminal (2. 21 0; 4, 1 02, 1 04). 

41. The system of claim 40. wherein the means for receiving the request for the proposed financial transaction 
^ further comprises a rate server (8. 204) coupled to the transaction server (6, 202). 

42. The system of claim 39. wherein the means for receiving the request for the proposed financial transaction 
further comprises a plurality of transaction servers (6. 202) coupled to the terminal (2, 210; 4. 102, 104). 

43. The system of claim 42, wherein the means for receiving the request for the proposed financial transaction 
^ further comprises the transaction servers (6, 202) of each of a plurality of independentiy maintained and 

segregated trading systems (216. 218) coupled to the terminal (2. 210; 4. 102. 104). 

44. The system of claim 43, wherein the means for receiving the request for the proposed financial transaction 
further comprises a corresponding rate sender (8, 204) coupled to the transaction server (6, 202) of each of tiie 

55 trading systems (216, 21 8). 



45. The system of claim 38, wherein the means for generating the rate quote for the proposed financial transaction 
further comprises means for identif/ing the first predefined condition for generating the executable rate quote. 
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46. The system of claim 45, wherein the means for identifying the first predefined condition for generating the 
executable rate quote further comprises at least one of a transaction server (6, 202) and a rate sen/er (8, 204). 

47. The system of claim 46, wherein the means for generating the rate quote for the proposed financial transaction 
further comprises the rate server (8, 204) for generating the executable rate quote coupled to the transaction 
server (6, 202). 

48. The system of claim 47, wherein the means for generating the rate quote for the proposed financial transaction 
further comprises the rate server (8, 204) of at least one of a plurality of independently maintained and 
segregated trading systems (216, 218). 

49. The system of claim 48, wherein the means generating the rate quote further comprises the rate sen/er (8, 204) 
coupled to a corresponding transaction server (6, 202) of the at Is least one independently maintained and 
segregated trading system (216, 218). 

50. The system of claim 38, wherein the means for generating the rate quote for the proposed financial transaction 
further comprises means for automatically identifying the second predefined condition for generating the category 
ti-ader's rate quote. 

51. The system of claim 50, wherein the means for automatically identifying the second predefined condition for 
generating the category trader's rate quote further comprises at least one of a transaction server (6, 202) and a 
rate server (8, 204). 

52. The system of claim 38, wherein the means for generating the rate quote for the proposed financial transaction 
further comprises means for automatically prompting entry of the category trader's rate quote by at least one of 
a plurality of category traders. 

53. The system of daim 52, wherein the means for automatically prompting entry of the category trader's rate quote 
further comprises at least one category trader's terminal coupled to a transaction server (6, 202). 

54. The system of claim 38, wherein the means for automatically prompting the user (12, 116, 208) for selection of 
the generated rate quote further comprises a terminal (2, 210; 4, 102, 104) consisting of one of a user's terminal 
(2, 210) and a sales trader's terminal (4, 102, 104). 

55. The system of claim 54, wherein the means for automatically prompting the user (12, 116, 208) for the selection 
of the generated rate quote further comprises at least one transaction server (6, 202) coupled to the terminal (2, 
210; 4, 102, 104). 

56. The system of daim 55, wherein the means for automatically prompting the user (12, 116, 208) for the selection 
of the generated rate quote further comprises a rate sen/er (8, 204) coupled to the transaction server (6, 202). 

57. The system of daim 54, wherein the means for automatically prompting the user (12, 116, 208) for the selection 
of the generated rate quote further comprises a plurality of transaction servers (6, 202) coupled to the terminal 
(2, 210; 4, 102, 104). 

58. The system of claim 57, wherein the means for automatically prompting the user (12, 116, 208) for the selection 
of the generated rate quote further comprises the transaction servers (6, 202) of each of a plurality of 
independentiy maintained and segregated trading systems (216, 21 8) coupled to the terminal (2. 21 0; 4, 1 02, 1 04). 

59. The system of daim 58, wherein the means for automatically prompting the user (12, 116, 208) for the selection 
of the generated rate quote further comprises a corresponding rate server (8, 204) coupled to the transaction 
server (6, 202) of each of the trading systems (216, 218). 

60. The system of daim 38, wherein the means for automatically holding the generated rate quote for a predefined 
period of time further comprises a counter. 

61. The system of claim 38, wherein the means for receiving the request for execution of the proposed transaction 
for the user (12, 116, 208) further comprises a terminal (2. 210; 4, 102, 104) consisting of one of a user's 
terminal (2, 210) and a sales trader's terminal (4, 102, 104). 

62. The system of daim 61, wherein the means for receiving the request for execution of the proposed transaction 
forte user (12. 116, 208) further comprises a transaction server (6. 202) coupled to the terminal (2. 210; 4, 102, 104). 

63. The system of daim 62, wherein the means for receiving the request for execution of the proposed transaction 
for the user (12. 116, 208) further comprises the fransaction server (6, 202) of one of a plurality of 
independently maintained and segregated trading systems (216. 218) coupled to the terminal (2, 210; 4. 102. 104). 
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64. The system of claim 38, wherein the means for automatically executing the proposed financial transaction 
further comprises a transaction server (6, 202) coupled to a hand-off server (7. 108, 206). 

65. The system of claim 64, wherein the means for automatically executing the proposed financial transaction 
5 further comprises the transaction server (6, 202) and the hand-off server (7, 108, 206) of one of a plurality of 

independentiy maintained and segregated trading systems (216, 218). 
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Customer Logs on Customer GUI and Enters Instrument ID, 
Volume, and Indicates Buy or Sell Warrant 






Customer GUI Validates Details and Sends Rate Quote 
Request to WTS 







WTS Receives Rate Request, Checks if 
Ccunteiparty/system Suspended; if No, Sends Rate Request 
to WRS, or if Yes, WTS Checks if Relevant RFQ 
Parameters Set; if No, Sends Rejection Message to 
Customer GUI, or if Yes, Sends Rate Request to WRS 



J 

WRS Receives Rate Request, Checks if Instrument/Rate 
Suspended; if No, WRS Checks if Deal Size Exceeds 
Available Volume, or if Yes, WRS Checks if Relevant RFQ 
Parameters Set; if No, Sends Rejection Message to WTS for 

Customer GUI, or if Yes, WRS Checks if Deal Size 
Exceeds Available Volume; if Deal Size Does Not Exceed 
Available Volume, WRS Sends Executable Rate to WTS, or 
if Deal Size Does Exceed Available Volume, WRS Checks 

if Relevant RFQ Parameter Set; if No, Sends Rejection 
Message to WTS for Customer GUI, or if Yes, Sends RFQ 
Message to WTS 



WTS Receives Executable Rate From WRS; WTS Checks if 

Deal Amount Exceeds Transaction Limit; if No, Sends 
Executable Rale to Customer GUI, or if Yes, WTS Checks - 
if Relevant RFQ Parameter Set; if No, WTS Sends 
Rejection Message to Customer GUI, of if Yes, WTS 
Determines RFQ is Required 



FIG. 6 
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WTS Receives RPQ Message From WRS or Deteimines RFQ is Required; Sends RFQ - S6 
Message to Customer GUI; Sends RFQ Notification to MAI 



Customer GUI Receives RFQ Message From WTS; Disables "Buy" Button and 
Enables "Re-Request" and "cancel" Buttons; Sets RFQ Timer 



MAI Receives RFQ Notification From WTS; Sends RFQ Notification to Trader _ S8 
GUI 



Trader GUI Displays RFQ Message on RFQ Message Screen 



Trader Enters Selection of RFQ From Message Screen 



Trader GUI Gels Transaction Dettils From WTS and Displays Transaction Details 
on Transaction Screen 



Trader Enters Acceptance by Pressing "Accept" Button or Rejection by Pressing - S 1 2 
"Reject" Button on Transaction Screen 



Trader GUI Sends Trader's Acceptance or Rejection to WTS 



WTS Sends Trader's Acceptance or Rqection to Customer GUI; Updates RFQ 
Status in WTS Transaction Database; Broadcasts Updated RFQ Status Via MAI to 
All On-Line Category Traders 



Customer GUI Receives Trader's Acceptance or Rejection; if Rejection, Displays 
Refiisal Message, and Enables "Re-Request" and "Cancel" Buttons; or if 

Acceptance, Displays Trader's Rate 



Customer Sees Display of Trader's Rate; Enters Customer's Rqection of Trader's 
Rate by Pressing "Cancel" Button; or, if Not Timed Out. Enters Acceptance of 
Trader's Rate by Pressing "Buy" Button and Transaction is Executed 



-S16 FIG. 7 
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Customer Telephones Sales Trader and Requests Warrants Transaction 



. SlOl 



Sales Trader at Sales Trader GUI Logs in and Inputs Name and 
Password Information and Enters Warrants SE No., KV No., or Depot 
No., if Known; Alternatively, Enters Counteiparty Bank Name; Presses 
"Get Price" Button 



Sales Trader GUI Sends Entered Information and Price Quote Request 
toWTS 



WTS Validates Entered Information; Checks RFQ Parameters and, if 
Applicable, Triggers RFQ Process, or if not Applicable, Sends Price 
Quote Request to WRS 



WRS Checks RFQ Parameters and, if Applicable, Triggers RFQ 
Process, or if Not, Generates Two- Way Buy-Sell Price Quote; Sends 
Price Quote to WTS 



WTS Sends Price Quote to Sales Trader GUI 



Sales Trader GUI Displays Price Quote on Sales Trader Deal Entry 
Screen; Sets Timer 



Sales Trader Receives Customer's Rejection of Price Quote on 
Telephone and Enters Rejection by Pressing "Cancel" Button; or 

Receives Customer's Acceptance and Desired Volume on Telephone 
and Enters Volume and, if Price Quote Not timed Out, Executes 

Transaction by Pressing "Buy" or "Sell" Button on Deal Entry Screen 



FIG. 16 
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FIG. 17 
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Customer Logs on and Enters Price Quote Request at Customer GUI 



Customer GUI Sends Price Quote Request Via Shared Communication and 
Messaging Layers Simultaneously to WTS of Each of a Plurality of 
Independently Maintained and Segregated Financial Institution Trading 
Systems 



WTS of Each Financial Institution Trading System Checks RFQ Parameters 
and, if Applicable, Triggers RFQ Process, or it Not Applicable, Sends Price 
Quote Request to its Corresponding WRS 



WRS of Each Financial Institution Trading System Generates and Returns 
Executable Rate Quote to its Corresponding WTS 



WTS of Each Financial Institution Trading System Sends Rate Quote Via _ gjos 
Shared Communication and Messaging Layers to Customer GUI 



Customer GUI Receives and Displays Executable Rate Quote From WTS of 
Each Financial Trading System, Such that the Rate Quote From the WTS of 
a Particular Financial Institution's Trading System and the Identity of the 
Particular Financial Institution is Known Only to the Particular Financial 
Institution and the Customer and Unknown to Each of the Other Financial 
Institutions 



Customer at Customer GUI Enters a Selection and Acceptance of a Rate 
Quote From the WTS of One of the Financial Institution Trading System 



Customer GUI Sends Customer's Selection and Acceptance Via the Shared 
Communication and Messaging Layers to the WTS of the Trading System 
Which Presented the Selected Rate Quote, Such that the Selection is Known 
Only to the Particular Financial Institution and the Customer and Unknown 
to Each of the Other Financial Institutions 



- S208 

FIG. 
18 



WTS of the Selected Financial Institution Trading System Receives the 
Customer's Selection and Acceptance and Sends to WHO of the Selected 
Financial Institution for Processing 



